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Abstract 

Model-based  reasoning  permits  diagnostic  applications  to  be  written  without  waiting  for 
someone  to  become  an  “expert”  of  the  system.  For  model-based  diagnostics,  there  must  be  a 
model  to  reason  from.  This  thesis  explores  using  a  VHDL  description  of  the  system  as  that  model. 
A  system  based  around  a  VHDL  interpreter  was  written  specifically  for  a  model-based  diagnosiic 
algorithm.  Curren  Jy,  the  diagnostic  system  uses  an  algorithm  by  Dries.  This  algorithm  was  derived 
from  Scarl’s  Full  Consistency  Algorithm.  The  system  was  designed  to  be  modular  so  that  different 
diagnostic  techniques  could  be  implemented.  It  is  divided  into  three  parts:  a  VHDL  parser,  a 
VHDL  interpreter,  and  a  set  of  routines  to  implement  Dries’  Diagnose  algorithm.  The  system  can 
find  stuck-at  faults  on  combinatorial  digital  circuits. 
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A  VHDL  Interpreter  for  Model-Based  Diagnoses 


7.  Introduction 


1.1  Background 

1.1.1  Model-Based  Diagnostics  Several  efforts  at  diagnosis  using  artificial  intelligence  have 
been  based  around  production  systems.  When  the  production  system  is  questioned  about  areas 
that  it  has  been  programmed,  the  system  can  give  an  answer.  However,  production  systems  have 
several  limitations.  The  first  is  the  expert:  there  must  be  someone  who  knows  how  the  unit  being 
diagnosed  works.  This  person  must  be  located,  and  a  knowledge  engineer  must  get  the  knowledge 
of  the  unit  being  diagnosed.  For  new  products,  there  may  not  even  be  an  expert.  Even  after 
the  expert  is  found,  the  expert  may  not  be  able  to  explain  his  knowledge  in  enough  detail  for  the 
knowledge  engineer  to  code  into  the  production  system. 

Assuming  the  knowledge  engineer  locates  the  expert,  and  that  the  knowledge  engineer  can 
translate  the  expert’s  knowledge  into  the  rules  for  the  production  system,  that  knowledge  still 
has  limitations.  If  the  production  system  is  presented  with  a  problem  for  which  it  has  not  been 
implicitly  or  explicitly  programmed,  it  is  unable  to  give  an  answer.  Since  the  production  system 
lacks  deep  knowledge  of  the  unit  being  diagnosed,  the  production  system  cannot  reason  beyond 
the  symptoms  it  was  programmed  to  recognize.  With  no  knowledge  on  how  the  system  works,  the 
production  system  cannot  reason  beyond  the  rules  that  are  programmed. 

Another  problem  with  production  systems  is  their  rigidity.  Once  the  production  system  has 
been  programmed  to  diagnose  one  kind  of  unit,  the  production  system  can  only  diagnose  that  one 
type  of  unit.  If  modifications  are  made,  or  if  the  unit  is  redesigned,  the  production  system  may  not 
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work  for  the  new  model.  Sometimes  the  production  system  can  be  updated,  but  this  could  require 
re-consulting  the  human  expert  on  the  system. 

Model-based  reeisoning  attempts  to  overcome  the  limitations  of  production  systems  by  at¬ 
tempting  to  “understand”  how  the  unit  being  diagnosed  works.  By  comparing  the  model  with 
the  faulty  unit,  and  by  knowing  relationships  between  the  components  of  the  unit,  model-based 
reasoning  attempts  to  find  out  which  component  or  components  are  at  fault.  Production  systems 
attempt  to  find  the  faulty  part  by  checking  programmed  knowledge  that  ties  symptoms  to  specific 
problems.  Model-based  reasoning  uses  knowledge  about  the  interconnections  of  the  parts,  as  well 
as  the  knowledge  on  how  each  part  is  supposed  to  work,  to  come  up  with  a  diagnosis.  Since  the 
model-based  reasoning  system  uses  a  model  of  the  unit  being  tested,  there  is  no  need  to  consult  an 
expert  about  every  possible  fault  that  can  happen. 

Compared  to  diagnostic  systems  based  on  production  systems,  model-based  reasoning  systems 
are  a  recent  development.  At  AFIT,  there  have  been  a  few  thesis  efforts  dealing  with  model-based 
reasoning.  In  1990,  Kenneth  Cohen  described  a  method  for  diagnosing  electronic  modules,  and 
implemented  an  assumption-based  truth  maintenance  system.  This  is  one  of  the  components  needed 
in  a  model-based  diagnostic  system.  Cohen’s  method  is  described  in  greater  detail  in  section  2.3. 
(1) 

Also  during  1990,  Flight  Lieutenant  Ralph  Dries  developed  a  system  for  detecting  anomalies 
in  a  satellite’s  pitch  and  velocity  control  subsystems.  A  model  of  the  satellite’s  subsystems  was 
modeled  in  Scheme/SCOOPS.  The'  diagnostic  system  used  model-based  reasoning  to  find  faults 
by  comparing  this  model  with  a  simulation  of  the  real  system.  Dries’  approach  is  discussed  in 
section  2. 5. (6) 

In  1988,  Captain  James  Skinner  used  a  combination  of  a  production  system  and  a  model- 
based  system  to  diagnose  the  Dual  Miniature  Inertial  Navigation  system.  In  his  Blended  Diagnostic 
System  (BDS),  the  system  uses  production  system  techniques  to  try  to  find  the  fault.  If  unsuc- 
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cessful,  the  BDS  tries  deep  model-based  reasoning  on  the  sub-unit  that  appears  to  be  at  fault. 
(14) 

Outside  AFIT  there  have  also  been  several  efforts  dealing  with  diagnostic  systems  based 
on  model-based  reasoning.  These  include  approaches  based  on  Reiter’s  Algorithm  and  abductive 
reasoning,  described  in  sections  2.6  and  2.7.  However,  there  has  not  been  much  done  on  describing 
the  model  for  the  reasoning  system. 

1.1.2  VHDL  VHDL  (VHSIC  Hardware  Description  Language)  is  a  hardware  description 
language  for  designing  Very  High  Speed  Integrated  Circuit  (VHSIC)  chips.  That  is,  VHDL  is 
a  software  system  that  simulates  a  hardware  system.  A  designer  can  use  VHDL  to  specify  the 
operation  of  the  VHSIC  circuits.  Once  the  designer  has  the  overall  behavior  of  the  circuit  specified, 
the  individual  components  can  be  broken  down  into  a  more  detailed  design.  This  can  go  all  the 
way  down  to  the  individual  gate  level.  As  each  subcomponent  is  designed,  its  behavior  can  be 
simulated  and  matched  against  the  specified  behavior. 

VHDL  uses  three  main  models:  a  timing  model,  a  structural  model,  and  a  behavior  model. 
A  VHDL  system  simulates  each  component  in  parallel.  The  timing  model  allows  the  VHDL  system 
to  simulate  each  component  in  operating  in  parallel  on  non-parallel  machines.  The  timing  model 
is  event  driven;  Each  process  (component)  schedules  the  transactions.  The  timing  model  allows 
VHDL  simulations  to  give  the  same  results  on  different  machines. 

The  structural  model  decomposes  the  complete  system  being  simulated  into  various  sub¬ 
systems.  This  creates  a  hierarchy  of  subsystems,  where  simple  subsystems  are  connected  into 
higher-level  subsystems.  Ultimately,  the  higher  level  subsystems  are  connected  to  form  the  com¬ 
plete  system.  Each  subcomponent  is  the  equivalent  of  a  “black  box,”  each  with  a  specified  set  of 
inputs  and  outputs. 
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The  behavioral  model  describes  how  each  subsystem  works.  This  is  one  of  the  most  complex 
parts  of  the  language.  The  behavioral  description  can  be  as  simple  as  single  operation,  or  can  be 
complex,  with  looping  and  conditional  operations. 

VHDL  is  a  powerful  language  for  hardware  description.  Although  it  is  primarily  used  for 
digital  design,  VHDL  has  analog  functions  that  should  allow  it  to  simulate  non-digital  systems. 
VHDL  has  been  standardized  by  the  IEEE  (IEEE-1076).  It  is  also  accepted  by  the  U.S.  Government 
as  a  standard  for  VHSIC  design(5:4). 

A  model-based  reasoning  system  requires  a  model.  Determining  the  model  of  the  system  to 
be  tested  can  be  a  difficult  task.  This  research  explored  using  VHDL  for  specifying  the  model. 

J.2  Problem 

One  of  the  problems  of  model-based  diagnostics  is  creating  a  model  of  the  system  to  be  tested. 
This  research  effort  is  use  a  VHDL  description  of  a  circuit  as  the  model.  This  avoids  the  need  to 
create  an  additional  model  for  the  diagnostic  system. 

J.3  Scope 

The  goal  of  this  research  was  to  design  and  implement  a  diagnostic  system,  named  Calvin, 
that  used  VHDL  to  describe  the  test  system.  Calvin  was  designed  so  that  it  can  be  extended  to 
handle  diagnostic  algorithms. 

The  following  limitations  applied  to  this  research; 

•  Tested  systems  were  feed-forward  combinatorial  digital  circuits. 

•  A  subset  of  the  VHDL  language  was  implemented.  The  subset  was  enough  to  describe  the 
above  circuits. 

•  The  VHDL  description  of  the  circuits  accurately  describe  the  operation  of  the  circuit. 
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•  Time-sensitive  bebjavior,  such  as  memory,  was  not  explored. 

•  Components  were  composed  of  only  lower-level  subcomponents,  or  boolean  algebra  descrip¬ 
tions. 

•  Only  the  following  faults  were  simulated: 

-  Output  stuck  high 

-  Output  stuck  low 

-  Input  stuck  high 

-  Input  stuck  low. 

•  If  an  input  was  stuck  high  or  low,  it  was  assumed  to  be  disconnected  from  the  rest  of  the 
system. 

•  The  tested  system  had  at  most  one  fault. 

J.4  Approach 

There  were  three  main  areas  in  this  research  effort:  Parsing  the  VttDL  language,  simulating 
the  circuit,  and  interfacing  a  diagnostic  method  to  Calvin.  There  also  must  be  some  means  for 
testing  Calvin. 

1.4  1  VHDL  Parser  The  parser  took  an  input  file  and  represented  it  internally.  A  VHDL 
grammar  written  for  the  GNU  Bison  compiler-compiler  was  used  as  the  skeleton  for  the  parser. 
This  implementation  is  described  in  Chapter  III.  Only  a  subset  of  the  VHDL  language  was  used 
for  Calvin;  unimplemented  VHDL  constructs  were  ignored. 

Objective:  Be  able  to  read  and  parse  the  VHDL  source  code  files  for  the  test  circuits. 

1.4  s  VHDL  Simulator  To  perform  model-based  reasoning,  there  must  be  some  way  to 
exercise  the  model.  In  this  research  effort,  VHDL  was  the  model;  therefore,  there  had  to  be  a  way 
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to  simulate  the  VHDL  source  code.  Although  there  are  already  VHDL  simulators  in  existence,  this 
system  was  designed  to  allow  easy  interfacing  to  diagnostic  routines. 

VHDL  is  a  complex  language;  a  full  implementation  of  the  language  is  well  beyond  the  scope 
of  this  research.  A  description  of  the  VHDL  subset  is  in  Appendix  A.  Chapter  III  describes  the 
implementation  of  the  simulator. 

Objective:  Be  able  to  simulate  test  circuits  and  generate  expected  values  of  the  VHDL  signals. 

I.4.S  Diagnostic  Routines  To  perform  the  diagnosis  on  the  test  circuits,  a  set  of  routines  was 
interfaced  with  the  VHDL  simulator.  The  goal  was  to  make  both  the  simulator  and  the  diagnosis 
routines  loosely  coupled.  Chapter  II  contains  previous  research  into  model-based  diagnosis. 

The  implementation  of  the  diagnostic  routines  is  discussed  in  Chapter  III,  along  with  a 
description  of  how  they  were  integrated  with  the  VHDL  portion  of  Calvin.  Chapter  IV  contains 
extensions  that  were  explored,  but  not  implemented  as  of  this  time. 

Objective:  Select  and  implement  a  model-based  diagnostic  strategy,  and  interface  it  with  a 
VHDL  simulator. 

1.4-4  Selection  of  Test  Circuits  To  test  Calvin,  there  needed  to  be  a  set  of  sample  circuits. 
Since  this  thesis  investigation  was  implementing  a  subset  of  the  source  language,  circuits  were 
selected  that  only  used  the  subset.  These  circuits  are  discussed  in  Chapter  IV. 

Objectives:  Create  a  sample  of  test  circuits  for  Calvin  to  analyze. 

1.5  Thesis  Overview 

The  next  chapter  reviews  some  model-based  diagnostic  methods  that  have  been  used  by  other 
researchers,  including  past  AFIT  thesis  efforts.  Chapter  III  describes  the  implementation  of  the 
VHDL  parser,  simulator,  and  diagnostic  routines.  The  results  of  the  implementation  of  Calvin 
are  discussed  in  Chapter  IV,  along  with  a  discussion  of  ways  to  enhance  the  diagnostic  routines. 
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Finally,  Chapter  V  will  state  the  conclusions  found  from  this  research,  along  with  recommendations 
for  future  efforts. 


II.  Literature  Review 


2.1  Introduction 

There  are  many  diflferent  ways  for  performing  model-based  diagnostics.  This  chapter  reviews 
algorithms  that  previous  researchers  developed.  Included  are  descriptions  of  model- based  research 
done  by  past  students  of  the  Air  Force  Institute  of  Technology.  This  chapter  concludes  with  a 
review  of  some  considerations  that  development  of  a  model  must  address. 

2.2  Reasoning  from  First  Principles 

One  method  of  model-based  reasoning  was  developed  by  Randall  Davis  in  1984.  In  it  he 
discussed  problems  with  previous  efforts  at  troubleshooting  systems.  Davis  proposed  to  solve  the 
problems  by  developing  a  system  that  reasons  from  first  principles,  using  knowledge  of  the  structure 
and  behavior  of  the  system  (4:347). 

To  reason  about  structure  and  behavior  requires  ways  of  representing  both.  Davis  based  his 
structure  description  on  three  ideas:  modules,  ports,  and  terminals  (4:352).  Modules  were  the  black 
boxes  that  made  up  the  system.  Information  flowed  in  and  out  of  the  modules  through  ports. 
Each  port  had  two  or  more  terminals:  one  on  the  outside  of  the  module,  and  one  or  more  on  the 
inside.  Modules  were  connected  by  superimposing  their  terminals  together.  There  were  no  separate 
entities  for  dealing  with  wires;  if  a  wire  was  explicitly  modeled,  it  was  simply  another  module.  The 
module  descriptions  were  hierarchical.  A  module  may  be  decomposed  into  submodules. 

The  behavior  of  the  system  being  tested  also  must  be  modeled.  To  support  Davis’  technique, 
the  behavior  of  the  modules  was  described  by  a  combination  of  simulation  rules  and  inference  rules. 
The  simulation  rules  described  the  output  of  the  module  as  a  function  of  its  inputs.  Inference  rules 
inferred  the  possible  values  of  one  input  as  a  function  of  the  rest  of  the  module’s  inputs  and  its 
output.  Simulation  rules  represented  the  flow  of  behavior,  while  inference  rules  represented  the 


8 


to  get 

sum 

from 

(input- 1  input-2) 

do  (+  input- 1 

input-2) 

to  get 

input- 1 

from 

(sum  input-2) 

do  (-  sum 

input-2) 

to  get 

input-2 

from 

(sum  input- 1) 

do  (-  sum 

input- 1) 

Figure  1.  Behavioral  Description  of  an  Adder  Module 
(4:357) 


flow  of  inference  (4:358).  An  example  of  a  behavioral  description  of  an  adder  module  is  shown  as 
Figure  1.  The  first  line  is  the  simulation  rule.  The  other  two  are  inference  rules. 

Davis  described  the  traditional  approach  to  troubleshooting  as  a  theory  of  test  generation, 
not  diagnosis  (4:360).  The  test  generation  approach  was  to  hypothesize  possible  faults,  and  then 
determine  a  set  of  input  values  that  would  logically  detect  that  fault.  This  approach  did  not 
provide  any  insight  on  determining  which  component  to  consider  next.  The  traditional  approach 
also  required  all  faults  to  be  explicitly  enumerated.  Other  faults,  such  as  those  caused  by  solder 
bridging  two  points  in  the  circuit,  could  not  be  diagnosed. 

To  avoid  the  problems  with  past  techniques,  Davis  proposed  the  use  of  discrepancy  detection. 
Instead  of  hypothesizing  faults,  this  technique  looked  for  observed  values  that  were  different  from 
the  simulated  values.  Misbehavior  was  then  defined  as  anything  that  wasn’t  correct  (4:362).  A 
dependency  network  contained  all  components  that  could  influence  the  incorrect  output.  The 
components  in  this  network  were  the  suspects  that  needed  to  be  checked.  Each  component  was 
checked  by  seeing  if  there  was  any  assignment  of  values  to  its  ports  that  could  produce  the  observed 
state  of  the  entire  system.  Since  to  do  this  required  that  the  behavior  of  the  suspected  component 
to  be  temporarily  ignored,  Davis  called  this  procedure  constraint  suspension.  If  a  consistent  set 
of  values  could  be  assigned  to  all  the  ports  in  the  system,  the  component  was  kept  as  a  possible 
suspect.  However,  if  there  was  no  way  to  assign  values  that  were  consistent  with  the  known  outputs, 
the  suspect  component  alone  could  not  cause  the  observed  behavior  (4:364). 
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2.S  Assumption-based  Truth  Maintenance  System 


In  1990,  AFIT  student  Kenneth  Cohen  developed  a  model-based  reasoning  system  that  was 
based  on  Davis’  reasoning  from  first  principles.  In  his  thesis,  Kenneth  Cohen  created  a  model- 
based  reasoning  system  that  consisted  of  three  parts:  a  model-miiker  module,  a  diagnostic  engine 
module,  and  a  truth  maintenance  system  module.  The  model-maker  module  was  used  to  model 
the  system  to  be  diagnosed.  The  model-maker  had  to  be  able  to  generate  “correct”  behavior  for 
the  system.  The  diagnostic  engine  module  compared  actual  observations  with  those  generated  by 
the  model-maker  module.  If  the  diagnostic  engine  detected  a  discrepancy,  the  diagnostic  engine 
attempted  to  find  the  cause  of  the  problem.  Using  constraint  suspension,  the  diagnostic  engine 
tested  sets  of  components  to  see  if  a  set  might  cause  the  observed  symptoms.  (1:17-27) 

The  main  thrust  of  Cohen’s  thesis  was  the  truth  maintenance  system  module,  called  the 
Assumption-based  Truth  Maintenance  System  (ATMS).  ATMS  was  a  method  for  keeping  track  of 
assumptions  for  a  model-based  diagnostic  system.  It  had  three  roles:  it  “remembered”  previously 
made  inference,  it  allowed  base  assumptions  to  be  made,  and  it  maintained  an  environment  free 
of  contradictions,  (1:30) 

By  remembering  inferences,  ATMS  reduced  computation.  If  a  component’s  value  had  been 
calculated  once,  that  value  would  not  have  to  be  recomputed  for  the  same  inputs  (1:30).  The 
second  role  was  to  allow  base  assumptions  to  be  made.  This  allowed  other  beliefs  to  be  reasoned 
(1:30).  ATMS  also  maintained  contradiction-free  environments.  Assumptions  were  usually  of  the 
form  “if  there  is  no  reason  to  believe  ->P  then  believe  P”  (1:31).  ATMS  retracted  any  assumptions 
that  conflicted. 

Since  Cohen  was  concentrating  on  the  ATMS,  he  did  not  implement  the  model-maker  module. 
Instead,  the  model  of  the  test  system  was  hard-coded  in  Lisp.  (1:36) 
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2-4  Full  Consistency  Algorithm 


A  different  approach  to  model-based  reasoning  was  developed  by  Scarl,  Jamieson,  and  De- 
laune.  Scarl’s  paper  described  a  prototype  system  for  monitoring  a  liquid-oxygen  expert  system. 
The  diagnostic  system,  cedled  LES,  determined  faults  from  sensor  data  using  knowledge  of  structure 
and  function  of  the  liquid  oxygen  system.  (13:360-361) 

LES  had  to  have  a  model  of  the  system  that  was  to  be  tested.  This  model  was  a  network  of 
objects,  each  representing  a  subcomponent  of  the  system  that  was  to  be  tested.  An  object  descrip¬ 
tion  contained  the  type  of  object.  Two  types  of  objects, commands  and  sensors,  contain  measured 
or  assigned  values  and  tolerances.  The  LES  algorithm  also  required  three  other  descriptors;  the 
source,  the  source-path,  and  the  status.  The  source  pointed  to  the  source  of  this  object’s  value. 
The  source-path  determined  if  this  object  was  connected  to  the  object  specified  by  the  source.  This 
value  was  a  boolean.  For  digital  objects,  these  descriptors  were  enough  to  describe  the  object.  If 
the  object  was  an  analog  object,  a  status  field  was  required  to  determine  the  state  of  the  object 
when  the  source-path  field  was  on.  (13:361-362) 

The  fields  in  the  object’s  descriptors  contained  expressions  that  determined  the  value  of  the 
object.  These  expressions  contained  the  names  of  other  objects  in  the  system  being  tested.  When 
calculating  the  value  of  the  object,  the  names  of  other  objects  were  replaced  with  the  value  of  the 
other  object  that  was  named.  (13:362) 

Objects  were  divided  into  three  categories;  commands,  components,  and  sensors.  The  com¬ 
mands  entered  values  into  the  system.  Components  took  values  at  their  input,  and  generated  an 
output  value.  Sensors  only  measured  a  value.  They  could  not  modify  any  other  object  in  the  sys¬ 
tem.  Information  in  the  model  only  flowed  in  one  direction,  from  outputs  of  objects  into  the  inputs 
of  other  objects.  Each  object  was  assumed  to  have  only  one  output,  which  could  be  connected  to 
the  inputs  of  several  objects.  (13:362) 


11 


The  LES  tested  for  faults  whenever  a  command  or  sensor  value  changed.  When  a  sensor 
reported  a  value,  it  was  checked  by  computing  its  expected  value.  LES  did  this  by  evaluating  the 
source-path  or  status  expressions.  Since  these  expressions  contained  the  names  of  other  objects, 
these  were  also  evaluated.  The  objects  were  recursively  evaluated  until  the  values  stored  in  the 
command  objects  were  reached.  If  the  observed  value  for  the  sensor  was  within  the  range  of  the 
calculated  value  for  that  sensor,  the  sensor  was  labeled  as  consistent.  If  the  observed  and  calculated 
values  did  not  match,  this  sensor  was  labeled  discrepant,  and  LES  invoked  the  diagnoser.  (13:364) 

When  a  command  value  was  changed,  all  sensors  affected  by  this  command  were  checked. 
The  LES  compared  observed  values  with  computed  values,  and  were  labeled  accordingly.  The  first 
sensor  that  didn’t  match  its  calculated  value  caused  the  diagnoser  to  be  invoked.  (13:364) 

During  diagnosis,  objects  were  labeled  innocent,  culprits,  or  suspect.  Innocent  objects  were 
those  objects  that  could  not  cause  the  faulty  value  of  the  sensor.  Culprits  were  those  objects  which 
LES  had  decided  could  cause  the  fault  sensor  value.  If  an  object  was  not  innocent  or  a  culprit,  it 
was  labeled  a  suspect.  The  sensor  that  didn’t  match  its  calculated  value  was  labeled  the  Original 
Discrepancy,  or  OD.  This  sensor  also  could  be  a  culprit,  a  suspect,  or  innocent.  (13:362) 

Scarl’s  Full  Consistency  Algorithm  for  finding  possible  faults  is  as  follows: 

1.  Pick  a  system  object  and  label  it  as  a  suspect.  Only  objects  that  are  upstream  from  the  OD 
are  considered.  LES  picks  suspect  objects  by  keeping  track  of  objects  visited  while  calculating 
the  expected  value  of  the  OD.  Since  the  sensor  itself  may  be  malfunctioning,  it  also  will  be 
picked  as  a  suspect  . 

2.  Hypothesize  a  faulty  state  for  the  suspect  object.  Since  the  correct  value  of  the  object  can 
be  calculated,  any  other  value  for  the  object  represents  a  faulty  state.  The  faulty  state  is  not 
picked  randomly.  Instead,  the  expressions  for  source-path  or  status  are  inverted.  Fault  states 
are  determined  based  on  these  inverted  expressions. 
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3.  Assume  the  faulty  state  for  the  object.  Simulate  the  system  and  determine  values  for  all  the 
sensors. 

4.  Compare  the  simulated  values  with  those  of  the  actual  system.  If  the  simulated  values  are 
consistent  with  those  actually  measured,  the  hypothesized  fault  is  one  possible  explanation  ol 
the  original  faulty  OD.  If  the  simulated  values  are  not  consistent  with  the  measured  values, 
the  hypothesized  fault  is  ruled  out. 

5.  If  the  simulated  and  measured  values  are  not  consistent,  and  there  are  more  possible  faults, 
loop  back  to  step  2  and  hypothesize  a  different  fault.  If  there  are  no  more  possible  faults  with 
the  object,  the  object  is  labeled  innocent 

(13:364) 

This  algorithm  requires  several  eissumptions.  The  system  must  not  have  any  feedback  loops. 
Only  one  fault  may  occur  at  a  time.  LES  could  handle  multiple  failures,  but  only  if  each  failure 
could  be  diagnosed  before  the  next  one  occurred.  The  equations  that  describe  the  objects  contained 
wild  card  values.  LES  used  these  to  represent  indeterminate  states.  These  were  used  to  switch 
out  objects  LES  had  determined  to  be  faulty.  The  algorithm  also  assumed  that  the  sensor  polling 
cycle  was  shorter  than  the  length  of  the  faulty  behavior.  LES  must  be  able  to  determine  the  faulty 
object  before  the  faulty  behavior  changed.  All  objects  in  the  system  being  tested  could  only  have 
one  output.  Those  objects  that  had  more  than  one  output  were  decomposed  into  sub-objects,  each 
containing  one  output.  Uncertainty  was  handled  by  using  ranges.  Tolerances  were  propagated 
backward  as  a  range  of  possible  values.  An  overlapping  range  would  match  an  expected  value  to  a 
measured  value.  (13:364) 

2.5  Model-Based  Reasoning  in  the  Detection  of  Satellite  Anomalies 

Flight  Lieutenant  Dries  used  Scarl’s  algorithm  to  develop  a  system  for  monitoring  an  Atti¬ 
tude  and  Velocity  Control  Subsystem  (AVCS)  of  a  geo-stationary  satellite.  Dries  modified  Scarl’s 
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algorithm  so  that  the  diagnostic  system  did  not  have  to  invert  the  description  of  a  component. 
Instead,  Dries  included  in  the  behavior  deecription  of  the  component  a  list  of  possible  faults.  For 
each  fault,  the  behavior  description  was  modified  so  that  the  fault  can  be  simulated. 

Dries  determined  several  characteristics  of  the  language  he  would  use  to  write  the  diagnostic 
system.  Because  the  system  model  would  be  written  in  the  language,  and  the  model  consisted  of  a 
network  of  objects,  an  object-oriented  language  would  be  required  (6:72-73).  Other  considerat'ons 
include  a  commonly  used  language  that  would  produce  efficient  code.  The  language  also  should  run 
or.  a  personal  computer.  This  would  reduce  development  cost,  since  PC’s  are  relatively  inexpensive 
and  are  readily  available  (6:73).  Languages  he  investigated  include  Smalltalk,  Lisp  with  Flavors, 
C-h-f  and  Scheme  with  SCOOPS. 

Originally,  Dries  tried  to  use  the  C-h-f  language  for  the  model  and  reasoner.  Borland  has  a 
C-f-f  compiler  that  is  known  for  its  efficient  code  generation  and  convenient  user  interface.  However, 
his  lack  of  familiarity  with  C,  along  with  C’s  steep  learning  curve,  prevented  him  from  using  C-t-h. 
He  then  turned  to  SCOOPS  to  develop  his  system.  Dries  chose  Scheme  for  its  simplicity,  symbol 
manipulation  and  fast  prototyping  ability  (6:75).  Both  the  model  and  the  model-based  reasoner 
were  written  using  SCOOPS,  an  object-oriented  extension  to  SCHEME.  He  concluded  that  C-f- f- 
probably  would  be  a  better  language  for  the  final  diagnostic  system  because  of  its  object-oriented 
capabilities  (6:75). 

The  components  of  the  AVCS  were  modeled  as  SCOOPS  objects  Using  the  object-oriented 
paradigm.  Dries  created  a  hierarchy  of  component  classes.  At  the  top  of  the  hierarchy  was  a  super¬ 
class  called  component.  This  class  contained  attributes  that  all  the  system  objects  have.  These 
included  a  name,  a  status,  a  list  of  objects  connected  to  this  object’s  inputs,  a  list  of  objects 
connected  to  this  object’s  output,  and  a  state  that  can  be  transmitted  to  the  objects  in  the  output 
list.  These  attributes  were  implemented  as  instvars,  or  instance  variables,  in  the  SCOOPS  object. 
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The  status  instvar  was  the  same  as  the  status  descriptor  described  by  Scarl.  The  source  instvar  of 
component  corresponded  to  Scarl’s  source  descriptor.  (6:78-79) 

The  individual  components  were  instances  of  the  component  class  and  its  subclasses.  SCOOPS 
automatically  generates  functions,  known  as  “methods”  for  getting,  setting,  and  initializing  at¬ 
tribute  values.  A  deposit-value  method  propagates  the  value  of  the  object  to  other  objects  in  the 
output-list. 

Below  the  component  class  in  the  hierarchy  was  the  amplifier  class.  Since  the  satellite  system 
was  primarily  analog,  most  of  the  components  were  of  the  amplifier  class  and  its  subclasses.  The 
amplifier  class  added  other  instvars  that  were  needed  by  amplifiers.  These  included  gain,  limit  and 
tolerance.  The  amplifier  class  also  contained  a  list  of  possible  faults,  such  as  latch-up,  high/low 
and  zero.  Dries  wrote  methods  for  this  class  that  would  simulate  the  operation  of  an  amplifier, 
along  with  possible  faults  states.  The  specific  components  of  the  AVCS  system  were  derived  from 
the  amplifier  class.  These  added  other  instvars  and  modify  the  simulation  methods.  (6:80-82) 

In  Scarl’s  system,  inputs  arrived  via  command  objects,  while  the  outputs  of  the  system  were 
measured  by  sensor  objects.  Dries  modeled  the  command  object  by  deriving  its  class  from  the 
component  class.  Since  a  sensor  could  itself  be  faulty,  it  weis  modeled  as  a  type  of  amplifier  with  a 
gain  of  1  and  a  tolerance  of  .0001.  The  sensor  class  also  contained  a  list  of  all  objects  upstream  of 
itself.  These  were  the  possible  objects  that  could  affect  this  sensor.  (6:94) 

The  pitch  control  channel  of  the  AVCS  was  modeled  by  a  network  of  instances  of  the  various 
classes.  For  Dries’  research,  two  networks  were  set  up:  one  to  represent  the  model,  and  one  to 
represent  the  real  subsystem.  The  SCOOPS  “make-instance”  instantiated  each  component.  The 
input  and  output  lists  formed  the  interconnections  of  each  network.  (6:95-97) 

As  stated  previously,  Dries  took  Scarl’s  Full  Consistency  Algorithm,  and  modified  it  for  his 
work.  Dries’  Reasoner  Algorithm  is  described  in  Figure  2. 
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Find  a  discrepant  sensor 
If  none  found  then 

No  fault  in  circuit 

Else 

Collect  all  components  structurally  upstream  from 
discrepant  sensor  and  put  into  suspect  list 
Repeat  for  each  suspect 

Repeat  for  each  fault  hypothesis 

Hypothesize  a  fault  for  the  suspect 
Propagate  change  through  the  model 
Test  all  sensors  for  consistency 
If  sensors  consistent  then 

Leave  suspect  in  suspect  list 

Else 

Clear  hypothetical  fault  (not  suspect) 
End-repeat  faults 
If  all  faults  are  ruled  out  then 
Clear  suspect 
End-repeat  suspects 
If  one  suspect  remains  then 
Print  out  the  culprit 

Else 

Print  out  the  list  of  suspects  remaining 


Figure  2.  Dries’  Diagnose  Algorithm 
(6:98) 


16 


Because  his  algorithm  was  based  on  Scarl’s  algorithm,  Dries’  Reasoner  algorithm  was  still 
subject  to  the  same  assumptions  and  limitations  of  Scarl’s  algorithm.  One  problem  Dries  encoun¬ 
tered  was  that  his  pitch  control  system  was  a  feedback  loop.  Since  neither  algorithm  would  work 
with  a  loop  in  the  test  system,  the  feedback  loop  had  to  be  broken  during  the  test  phase  (6:98). 
Instead  of  connecting  the  actual  objects  in  the  networks,  Dries  wrote  a  test-loop  function  that  took 
the  output  of  the  system  and  injected  it  back  into  the  input.  When  a  fault  was  introduced  into  the 
system,  the  feedback  loop  in  the  model  system  was  broken,  and  the  diagnostic  model  invoked. 

Another  limitation  of  Scarl’s  algorithm  was  that  objects  could  not  be  time  dependent.  Dries 
overcame  this  by  modifying  the  time  dependent  objects  so  they  were  non-time  dependent.  Dries’ 
system  was  still  able  to  detect  faults  in  those  modified  objects.  (6:35) 

When  Dries  ran  his  diagnostic  program,  the  program  was  able  to  find  almost  all  the  faulty 
components  he  introduced.  He  concluded  that  this  was  a  result  of  the  model  and  the  test  system 
being  exactly  the  same  (6.109).  Both  the  model  and  the  pitch  control  system  were  made  of  the 
same  SCOOPS  objects.  Dries  stated  that  a  better  test  of  his  system  would  be  to  use  a  more  realistic 
real-world  simulation,  but  at  the  same  time  use  a  computer  model  without  time  dependent  objects 
(6:109). 

2.6  Reiter’s  Algorithm  with  Enhancements 

This  approach  is  an  extension  of  Reiter’s  Algorithm.  Where  Reiter’s  algorithm  was  applied 
only  to  diagnosing  digital  circuits,  this  extension  would  cover  systems  that  vary  over  time. 

In  Reiter’s  algorithm,  called  DIAGNOSE,  a  problem  consisted  of  a  set  of  system  descriptions 
(SD),  a  set  of  the  .system’s  components  (called  COMP),  and  a  list  of  observations  of  the  system 
(OBS).  A  diagnosis  was  a  subset  of  COMP  that  consists  of  faulty  components.  SD  U  OBS  (the 
description  of  the  system,  together  with  observations  of  the  system)  must  be  valid  assuming  all 
the  components  of  the  subset  were  faulty,  and  all  components  not  members  of  the  subset  were  not 
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faulty.  A  conflict  set  was  a  set  of  components  such  that  assuming  all  the  components  in  the  set  are 
normal  is  inconsistent  with  SD  U  OBS.  (9:10) 

The  DIAGNOSE  algorithm  computed  a  set  of  all  diagnoses  by  building  a  search  tree,  called 
a  pruned  HS-tree  (heuristic  search  tree).  Nodes  of  this  tree  were  labeled  with  a  conflict  set,  while 
the  edges  were  set  by  a  system  component.  Each  node  had  a  path  label,  which  is  the  set  of  all 
edge  labels  from  the  root  to  that  node.  The  algorithm  required  a  consistency  checking  module, 
called  TP.  This  module  took  the  SD,  OBS  and  a  subset  of  COMP.  It  returned  a  conflict  list,  if  one 
existed.  Otherwise,  it  returned  null.  (9:10) 

The  HS-tree  was  set  up  by  calling  TP,  passing  it  the  entire  COMP  list.  The  root  node  was  set 
to  the  returned  conflict  list.  Then,  for  each  element  in  that  conflict  list,  a  child  node  was  created.  It' 
was  connected  to  its  parent  node  with  an  edge  labeled  by  the  element.  The  path  label  was  then  set 
to  be  the  path  from  the  root  to  that  node.  TP  was  called  with  the  COMP  list  minus  the  elements 
in  this  path.  The  returned  conflict  list  was  the  label  for  the  child  node.  If  0  was  returned,  the  child 
node  was  marked  as  completed.  When  the  HS-tree  was  completed,  the  set  of  diagnoses  was  the  set 
of  all  the  path  labels  of  the  nodes  marked  completed.  (9:10-11) 

This  paper  described  a  way  to  extend  Reiter’s  DIAGNOSE  algorithm  to  handle  time-varying 
systems,  as  well  as  continuous  devices.  The  continuous  device  was  broken  into  a  set  of  components. 
Each  component  was  described  by  one  or  more  equations.  It  was  assumed  that  the  continuous 
device  can  be  modeled  by  a  component-connection  model  (9:11).  Each  constraint  also  could  be 
localized  to  one  particular  component.  This  means  that  a  constraint  that  was  broken  could  be 
traced  to  one  faulty  component.  SD  was  then  set  as  the  qualitative  restraints  of  the  system, 
and  OBS  as  the  set  of  qualitative  states.  The  TP  module  was  a  constraint  propagation  module. 
When  it  was  called  with  a  subset  of  components,  all  restraints  are  removed  except  those  related 
to  the  component  subset.  The  propagator  attempted  to  propagate  the  parameter  values  as  much 
as  possible.  If  a  propagation  was  made  by  using  a  constraint,  the  constraint  was  marked  as  used. 
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If  an  inconsistency  was  detected,  the  TP  module  stopped  and  returned  a  list  of  components  that 
have  had  one  of  their  constraints  marked.  If  the  propagation  halted  with  no  inconsistencies,  the 
TP  module  returned  the  empty  set.  This  meant  that  all  the  components  passed  to  the  module  were 
normal.  (9:11-13) 

To  handle  continuous  devices,  the  DIAGNOSE  algorithm  was  run  using  the  initial  set  of 
observations.  The  conflict  sets  generated  would  have  at  least  one  faulty  component.  When  a  new 
observation  was  made,  all  the  nodes  marked  completed  were  opened.  The  TP  module  was  then 
ceilled  on  each  of  these  nodes,  this  time  using  the  new  observations.  This  was  done  until  all  the 
nodes  had  been  processed.  The  final  set  of  completed  nodes  became  the  new  diagnosis  set.  (9:13-14) 

f.  7  AbducUve  Diagnostic  Reasoning 

One  problem  with  Reiter’s  Algorithm  was  that  it  might  not  pick  the  most  “probable”  faulty 
component.  For  example,  assume  a  component  can  cause  one  symptom  95%  of  the  time,  and  a 
second  symptom  5%  of  the  time.  A  different  component  could  cause  the  second  symptom  90%  of 
the  time,  but  would  never  show  the  first  symptom.  Reiter’s  algorithm  would  say  that  the  only  first 
component  was  faulty,  even  though  it  was  more  probable  that  both  components  were  faulty  (8:16). 
Abductive  reasoning  attempted  to  choose  the  most  probable  set  of  disorders. 

Abductive  reasoning  was  based  on  a  causal  network,  a  directed  graph  that  describes  the 
problem  domain.  The  nodes  were  a  set  of  events  that  include  disorders,  symptoms,  and  pathological 
states.  The  edges  of  the  network  were  direct  causation  events.  They  connected  an  event  that  could 
directly  cause  another  event  with  no  known  intervening  events.  A  problem  was  stated  by  a  list  of 
observations,  each  being  a  node  in  the  causal  network.  Scenarios  were  chains  of  causation  events. 
Causal  explanations  were  scenarios  that  hold  true  for  the  problem’s  observation  set.  Abductive 
reasoning  attempts  to  find  the  causal  explanation  that  was  most  probable.  (8:17-18) 
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Each  causal  event  was  a  given  a  probability  when  the  causal  network  was  constructed.  The 
probability  of  a  scenwio  was  the  product  of  the  casual  events  that  make  up  the  scenario  (8:18).  The 
goal  is  to  maudmize  the  probability  of  a  scenario  that  explained  all  observations.  This  became  a 
variation  of  the  Steiner  Problem,  a  NP-Complete  problem  (8:19).  The  rest  of  this  paper  described 
an  approach  for  reducing  complexity  to  polynomial  time  to  the  number  of  nodes  in  the  network. 

2.8  Modeling  Digital  Circuits  for  Troubleshooting 

In  this  paper,  Hamscher  discussed  problems  with  current  models  used  in  model  based  reason¬ 
ing.  He  described  a  situation  where  a  field  engineer  could  diagnose  and  fix  a  circuit  in  ten  minutes 
using  only  a  few  probes  and  swapping  one  chip.  A  model-based  troubleshooting  program  took 
an  entire  day,  and  then  concluded  that  any  of  40  chips  or  400  wires  could  be  responsible  for  the 
problem  (7:2).  To  overcome  this  problem  Hamscher  proposed  incorporating  knowledge  on  how  the 
component  could  fail  in  the  circuit  model.  He  gave  eight  principles  for  modeling  digital  circuits. 
These  are  summarized  here: 

1.  Components  in  the  model  should  correspond  to  possible  repairs.  There  is  no  point  in  deter¬ 
mining  which  transistor  in  the  chip  is  bad.  If  any  part  of  the  chip  is  baa,  the  whole  chip  will 
need  to  be  replaced.  This  cuts  down  on  the  processing  time  spent  in  diagnosis.  (7:6) 

2.  Model  components  should  simplify  behavioral  abstraction.  The  only  reason  to  represent  a 
function  in  the  model  is  to  make  the  behavior  prediction  more  efficient.  If  it  is  easier  for  the 
diagnostic  system  to  reason  about  a  group  of  components,  group  the  components.  (7:6) 

3.  Component  behavior  should  represent  features  easy  for  the  troubleshooter  to  observe.  Some 
features  are  easier  and  more  efficient  to  observe  than  others.  (7:7) 

4.  Components  whose  behavior  changes  every  time  its  inputs  change  should  be  represented  in 
temporally  coarse  terms.  More  powerful  representations  take  into  account  the  function  of 
the  circuit  over  long  periods  of  time.  Hamscher  gives  as  an  example  the  number  of  mouse 
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increments  per  second  determining  the  number  of  times  an  interrupt  line  would  be  asserted. 
(7:7) 

5.  A  temporally  coarse  description  that  only  describes  some  of  the  component’s  behavior  is 
better  than  no  description  at  all.  An  example  would  be  a  microprocessor  chip  interfaced  to 
the  mouse.  The  relationship  between  the  motion  of  the  mouse  and  the  interrupts  lines  only 
holds  true  if  the  clock  is  running.  The  troubleshooting  program  can  still  use  this  behavior  to 
find  faults,  though  the  entire  function  of  the  microprocessor  is  not  simulated.  (7:7) 

6.  Encapsulate  sequential  circuits  into  a  single  component.  This  cuts  down  on  the  number 
of  behaviors  that  the  troubleshooter  must  consider.  The  overall  resulting  behavior  makes 
reasoning  about  the  behavior  more  efficient  than  considering  the  various  behaviors  of  the 
components  of  the  circuit.  (7:7) 

7.  If  there  are  known  likely  failures  in  a  component,  represent  the  failure  mode  in  the  model. 
This  can  reduce  the  number  of  different  diagnoses.  (7:7) 

8.  If  a  component’s  misbehavior  is  much  easier  to  model  than  the  correct  behavior,  include 
the  misbehavior  in  the  component’s  model.  If  a  component  with  complex  behavior  fails 
completely,  then  any  partially  correct  behavior  can  make  the  component  a  much  less  likely 
suspect.  Since  a  complete  malfunction  can  usually  be  easily  modeled,  the  troubleshooting 
system  can  efficiently  detect  the  failures  if  they  are  explicitly  modeled.  (7:7) 

2.9  Summary 

This  chapter  reviewed  some  current  methods  that  researchers  are  using  to  perform  model- 
based  diagnostics.  One  recurring  problem  is  how  to  model  the  system.  This  effort  will  use  VHDL 
as  a  way  of  specifying  a  model.  The  implementation  of  such  a  system  is  discussed  in  the  next 
chapter. 
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III.  Implementation 


3.1  Overview 

3.1.1  Introduction  For  a  model-based  diagnostic  system,  there  obviously  must  be  some  way 
to  model  the  system  to  be  diagnosed.  One  way  of  modeling  the  system  is  to  use  some  form  of 
hardware  description  language.  This  thesis  will  use  VHDL  as  that  language. 

3.1.2  The  VHDL  Language  VHDL  was  created  primarily  for  the  design  and  verification 
of  large-scale  integrated  circuits  (10:2).  Its  very  name,  VHSIC  Hardware  Description  Language, 
signifies  it  as  a  language  for  describing  (modeling)  hardware.  MIL-STD  454L  requires  that  all  new 
application-specific  integrated  circuits  will  have  a  VHDL  description  (5:4.5. 1). 

VHDL  has  several  basic  building  blocks  which  my  diagnostic  system,  named  Calvin,  must 
implement.  These  include  Entities,  Architectures,  Configurations,  and  Processes.  Others  will  be 
left  for  future  research. 

In  VHDL  the  Entity  is  the  most  basic  block  in  the  design  (10:3).  The  entity  specifies  what 
objects  exist  in  the  system.  They  are  arranged  in  a  hierarchy,  with  the  top  entity  representing  the 
system  itself. 

The  Architecture  describes  how  an  entity  behaves.  There  are  two  types  of  architectures: 
Behavioral  and  Structural.  The  Behavioral  architecture  describes  how  the  entity  behaves  in  terms 
of  VHDL  statements.  The  Structural  architecture  describes  the  architecture  as  interconnections  of 
entities  that  make  up  the  architecture.  This  creates  the  system  hierarchy. 

Since  an  entity  may  have  more  than  one  architecture,  there  must  be  some  way  to  specify 
which  architecture  to  use  for  the  entity.  VHDL  uses  the  Configuration  to  bind  the  instances  of  an 
entity  to  a  specific  architecture. 
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The  basic  simulation  block  of  the  system  is  described  by  Processes.  The  behavioral  architec¬ 
tures  contain  one  or  more  processes  to  describe  the  operation  of  that  architecture.  All  processes 
are  assumed  to  be  operating  in  parallel. 

3.1.3  Diagnose  Algorithm  After  determining  how  the  test  system  was  to  be  modeled,  the 
next  step  was  to  determine  if  there  was  an  error.  When  the  diagnostic  system  detected  an  error, 
the  diagnostic  system  needed  some  method  of  determining  which  component  of  the  test  system 
was  at  fault.  Although  there  were  many  methods,  some  of  which  were  discussed  previously,  this 
research  used  a  method  originated  by  Scarl  and  used  in  a  previous  thesis  by  Dries.  This  algorithm 
is  shown  in  Figure  3.  The  method  this  research  used  had  two  advantages: 

•  No  need  to  “invert”  the  VHDL  source.  Diagnostic  methods  such  as  those  used  by  Davis 
required  a  way  for  determining  the  inputs  of  a  system,  given  the  values  of  the  outputs. 

•  Fits  in  with  a  simulator-based  modeling  system.  Possible  faults  in  the  individual  components 
were  determined  before  diagnoses.  This  allowed  more  work  to  be  done  before  the  actual 
diagnosis. 

However,  there  were  also  a  few  disadvantages: 

•  No  feedback.  Neither  Scarl’s  full  consistency  algorithm  nor  Dries’  diagnose  algorithm  allowed 
the  test  circuit  to  have  any  feedback.  This  prevented  state  machines  from  being  tested.  Dries 
worked  around  this  limitation  by  breaking  the  feedback  loop  during  diagnostics. 

•  Limited  fault  detection.  The  set  of  faults  the  system  will  look  for  were  predetermined  before 
diagnosing  the  test  circuit.  If  an  unforeseen  fault  occurred,  the  system  could  not  find  it. 

•  Combinatorial  explosion.  The  time  needed  to  diagnose  a  system  was  dependent  on  the  number 
of  suspects.  This  in  turn  was  dependent  on  the  depth  and  branching  factor  of  the  test  circuit. 
In  an  extreme  case  with  only  one  sensor,  every  component  would  be  suspect.  This  would 
result  in  testing  every  hypothesis  for  every  component  in  the  test  circuit. 
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The  system’s  diagnostic  method  should  be  easily  updated  when  needed.  This  was  done  by 
a  combination  of  object-oriented  programming  and  loosely  coupled  modules.  The  algorithm  was 
divided  into  two  areas:  Generate  and  Test. 

S.  1.3.1  Generate  Calvin  first  generated  the  various  hypotheses  for  each  component. 
This  was  done  during  the  parsing  of  the  VHDL  model.  As  an  executable  section  of  the  model  was 
parsed,  the  parsed  data  was  sent  to  the  hypothesis  generator  to  determine  what  could  go  wrong. 
Each  simulation  component  contained  a  set  of  instructions  on  how  it  was  supposed  to  logically 
work.  This  section  took  the  correct  model  and  generated  the  faulty  behaviors.  Although  currently 
this  portion  is  only  executed  during  parsing,  it  can  be  extended  to  be  executed  during  simulation. 

For  this  effort  four  common  hypotheses  for  digital  circuits  were  generated: 

1.  Input  stuck  high.  This  simulates  the  case  where  the  input  of  a  component  always  reads 
“high.” 

2.  Input  stuck  low.  This  is  where  the  input  always  reads  “low.” 

3.  Output  stuck  high.  This  simulates  an  output  that  is  always  high.  This  may  seem  to  be 
the  same  as  if  an  input  connected  to  that  output  was  stuck  high.  The  difference  is  in  this 
hypothesis  all  inputs  connected  to  the  output  will  be  pulled  high. 

4.  Output  stuck  low.  This  is  where  the  output  line  always  reads  low. 

3. 1.3. 2  Test  This  portion  implements  Dries’  Diagnose  algorithm.  Figure  4  describes 
the  algorithm  used  by  Calvin. 

After  Calvin  found  an  output  that  did  not  match  its  simulated  value,  the  component  attached 
to  that  output  was  placed  in  a  suspect  list.  Then,  Calvin  works  upstream,  placing  each  component 
into  the  suspect  list  until  the  inputs  were  reached.  Calvin  did  this  by  using  the  structure  of  the 
test  circuit. 
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Find  a  discrepant  sensor 
If  none  found  then 

No  fault  in  circuit 

Else 

Collect  all  components  structurally  upstream  from 
discrepant  sensor  and  put  into  suspect  list 
Repeat  for  each  suspect 

Repeat  for  each  fault  hypothesis 

Hypothesize  a  fault  for  the  suspect 
Propagate  change  throughout  the  model 
Test  all  sensors  for  consistency 
If  sensors  consistent  then 

Leave  suspect  in  suspect  list 

Else 

Clear  hypothetical  fault  (not  suspect) 
End-repeat  faults 
If  all  faults  are  ruled  out  then 
Clear  suspect 
End-repeat  suspects 
If  one  suspect  remains  then 
Print  out  the  culprit 

Else 

Print  out  the  list  of  suspects  remaining 


Figure  3.  Dries’  Reasoner  Algorithm 
(6:98) 

Calvin  took  each  suspect  from  the  list  and  tried  to  determine  if  it  could  cause  the  problem.  It 
went  through  the  hypotheses  that  were  created  during  the  initial  parsing,  and  simulated  the  fault. 
The  VHDL  simulator  was  then  rerun  to  see  if  that  fault  could  account  for  the  all  the  known  output 
values.  If  so,  that  hypothesis  was  kept;  otherwise  it  was  thrown  out.  This  process  was  repeated  for 
the  rest  of  the  hypotheses  and  suspects. 


3.2  The  Calvin  Diagnostic  System 

A  diagram  of  the  Calvin  system  is  shown  in  Figure  5.  There  are  three  main  units  in  Calvin; 
the  VHDL  parser,  the  VHDL  simulator,  and  the  diagnostic  routines.  In  Figure  5  the  diagnostic 
routines  are  in  the  /nit.  Hypothesis  Generator  and  diagnostic  blocks.  The  code  that  controls  the 
program  flow  is  contained  mostly  in  the  modules  CALVIN  and  MAIN. 
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Check  sensors 

Collect  suspects 
While  more  suspects 

While  more  hypotheses 
Hypothesize  fault 
Re-simulate 

Compare  all  sensors  with  their  simulated  values 
If  consistent 

Keep  suspect 

Else 

Remove  suspect 

End 

End 

End 


Figure  4.  Calvin’s  Diagnostic  Algorithm 

The  VHDL  parser  takes  the  source  code  and  generates  an  internal  representation  of  the  circuit. 
While  the  parser  is  generating  this  representation,  the  data  is  sent  to  a  hypothesis  generator.  This 
module  creates  code  to  simulate  the  errors  that  Calvin  will  check  for  during  diagnosis.  The  simulator 
takes  a  current  representation  of  the  circuit  and  its  inputs  and  determines  what  the  outputs  should 
be.  This  is  done  first  to  check  the  outputs  of  Calvin’s  model  of  the  circuit  against  the  measured 
outputs  of  the  circuit.  The  simulator  is  also  used  to  re-simulate  the  circuit  after  a  fault  is  introduced. 
The  diagnostic  routines  implement  a  version  of  Dries  Diagnose  algorithm.  These  routines  call  the 
simulator  modules  as  needed  for  re-simulation. 

The  Init  block  in  Figure  5  is  further  broken  down  in  Figure  6.  First,  Calvin  initializes  the 
internal  variables.  Calvin  then  parses  the  command  line  to  get  the  VHDL  source  file  name,  test 
inputs  and  outputs  file  name,  and  commands.  An  example  is  given  in  section  4.1.1.  The  VHDL 
source  file  is  then  opened  and  sent  to  the  parser. 

The  VHDL  parser  takes  a  file  containing  the  VHDL  description  of  the  system  to  be  diagnosed 
and  generates  an  internal  representation  of  the  system.  During  this  parsing,  the  internal  represen- 
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HYPOTHESIS 


Figure  5.  The  Calvin  System 


Figure  6.  Calvin  Initialization 


tation  is  handed  over  to  a  diagnostic  module  to  generate  possible  faults.  This  is  the  Hypothesis 
Generator  shown  in  Figure  5. 

The  next  step  is  to  get  the  current  inputs  and  outputs  of  the  actual  circuit  (called  by  Scarl 
commands  and  sensors).  These  are  contained  in  the  test  file  specified  on  the  command  line.  The 
input  signals  are  set  to  these  values.  Control  is  given  to  the  last  block  in  Figure  6,  First  Check. 

First,  the  VHDL  simulator  is  called  to  generate  the  sensor  values  that  Calvin  expects  for  a 
correctly  operating  circuit.  Calvin  then  compares  these  values  with  those  reported  in  the  test  file. 
This  is  detailed  in  Figure  7.  Calvin  loops  through  each  sensor  and  compares  its  simulated  correct 
behavior  with  that  of  the  “real  world.”  If  all  the  sensors  match,  Calvin  decides  that  there  are  no 
faults  and  quits.  Otherwise,  the  system  calls  the  diagnostic  routines.  These  routines  implement 
a  version  of  Dries’  Diagnose  algorithm,  re-simulating  the  circuit  as  necessary.  This  is  detailed  in 
Figure  8.  Possible  suspects  are  collected  based  on  which  sensor  does  not  match  the  simulated  value. 
This  routine  is  detailed  in  section  3. 2. 3. 2.  The  suspects  are  collected  in  a  queue.  While  there  are 
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First  Check 


Diagnose 


Figure  7.  First  Sensor  Check 


still  suspects,  Calvin  takes  one  off  the  top.  Calvin  then  runs  through  the  possible  hypotheses  for 
this  suspect.  Each  hypothesis  is  implemented  in  the  simulated  circuit,  and  the  VHDL  simulator 
is  called.  The  newly  simulated  values  are  compared  against  those  in  the  test  file.  If  they  match, 
Calvin  reports  that  this  is  a  possible  fault  in  the  circuit.  Otherwise,  Calvin  rejects  the  hypothesis 
and  selects  the  next.  Once  all  the  hypotheses  are  finished,  Calvin  goes  to  the  next  suspect  in  the 
queue.  When  all  of  the  suspects  are  checked,  Calvin  quits. 


S.2.1  VHDL  Parser  The  parser  section  takes  as  its  input  the  name  of  the  file  that  contains 
the  VHDL  source  code.  Using  a  subset  of  the  VHDL  language,  it  generates  a  set  f>f  data  structures 
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Diagnose 


Figure  8.  Calvin’s  Diagnostic  Algorithm 
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-  Entity  declaration  for  1/6  of  74xx04  inverter 
entity  7404Jnv  is 
port( 

A:  in  bit; 

Y:  out  bit 

)i 

end  7404 Jnv; 


Figure  9.  Entity  Declaration  for  7404  Type  Inverter 


-  Architecture  body  for  1  /6  of  74L04  inverter 

-  Propagation  delay  determined  by  the  average  of  pLH  and  pHL 

-  as  given  by  the  TTL  Data  Book,  Vol.  2  by  Texas  Instruments 
architecture  74L04Jnv  of  7404Jnv  is 

begin 

process 

Y  <=  not(A)  after  33  ns; 
wait  on  A; 
end  process; 
end  74L04Jnv; 


Figure  10.  Architecture  Body  for  74L04  Inverter 

that  represent  the  parsed  source  code.  The  grammar  of  the  VHDL  subset  used  in  this  research  is 
described  in  Appendix  A. 

The  first  part  of  the  source  code  file  contains  entity  and  architecture  declarations.  The  entity 
declaration  defines  the  components  that  make  up  a  circuit,  along  with  their  interfaces.  The  actual 
workings  of  the  component  are  described  by  the  architecture  declaration.  Since  there  can  be  many 
ways  to  describe  the  internal  workings  of  a  component,  there  can  exist  more  than  one  architecture 
declaration  for  an  entity  declaration.  For  an  example  of  multiple  architectures  for  the  same  entity 
consider  the  TTL  7404  inverter.  A  possible  entity  declaration  for  the  gate  is  shown  as  Figure  9.  The 
characteristics  of  the  gate  vary  depending  on  the  technology  used.  An  architecture  body  for  the 
74L04  inverter  is  shown  in  Figure  10.  while  the  architecture  body  for  a  74S04  inverter  is  described 
in  Figure  11.  The  parser  maintains  a  list  of  currently  defined  entity  declarations  and  architecture 
bodies  that  have  been  declared  in  the  source  code  file. 
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-  Architecture  body  for  1  /6  of  74S04  inverter 

-  Propagation  delay  determined  by  the  average  of  pLH  and  pHL 

-  as  given  by  the  TTL  Data  Book,  Vol.  2  by  Texas  Instruments 
architecture  74S04  Jnv  of  7404 Jnv  is 

begin 

process 

Y  <=  not(A)  after  4  ns; 
wait  on  A; 
end  process; 
end  74S04Jnv; 


Figure  11.  Architecture  Body  for  74S04  Inverter 

configuration  decode.llcon  of  decode  is 
for  structural 

for  II;  inv  use  configuration  work.invcon; 
end  for; 
end  for; 

end  decode.llcon; 

Figure  12.  Configuration  for  Structural  of  Decode 
(4:123) 

The  VHDL  simulator  requires  a  set  of  processes  and  their  interconnections.  The  code  for 
the  processes  is  generated  when  the  parser  finds  process  definitions  within  the  architecture  bodies. 
After  the  code  for  a  process  has  been  generated,  it  is  handed  over  to  the  diagnostic  module.  The 
diagnostic  module  generates  possible  fault  hypotheses  for  the  process,  and  returns  it  to  the  parser. 
The  parser  takes  the  correct  behavior  and  the  hypothesized  faults,  and  collects  them  into  a  block 
for  the  simulator  to  use. 

Which  architecture  is  used  by  the  simulation  is  determined  by  the  configuration  source  code. 
An  example  configuration  is  shown  as  Figure  12.  In  this  implementation,  the  parser  expects  a 
VHDL  configuration  to  be  at  the  end  of  the  source  code  file.  When  the  parser  has  reached  the  end 
of  the  source  file,  it  returns  control  to  the  main  program. 
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Initialize  activation  record  queue 
while  queue  not  empty: 

Get  next  time 

while  new  time  ==  time  of  next  record  on  queue: 

Compare  new  value  of  signal  described  by  the  record  with  the 
current  value.  If  they  are  equal,  throw  out  record  and  loop. 
If  not,  add  record  to  set  of  signals  to  update. 

Set  value  of  signal  to  new  value  described  by  record 
Collect  all  behavior  instances  whose  input  is  connected  to 
this  signal. 

For  each  behavior  instance  collected: 

Determine  which  process  code  is  to  be  executed 
Execute  code,  posting  new  signal  values  to  the  queue 


Figure  13.  VHDL  Simulator  Pseudo-code 

3.S.2  VHDL  Simulator  The  simulator  is  based  on  an  Intermetrics  VHDL  system.  This 
VHDL  system  was  described  by  Comeau  in  Chapter  III  of  his  thesis  (3:41-61).  The  basic  operation 
of  the  simulator  is  described  by  Figure  13. 

The  simulator  revolves  around  a  priority  queue  that  contains  information  for  updating  the 
various  signals  in  the  simulation.  These  activation  records  contain  information  on  which  signal  is 
to  be  updated  next,  and  how  it  is  to  be  updated. 

The  first  time  the  simulator  is  run,  a  routine  is  called  which  places  activation  records  for 
all  the  signals  present  in  the  simulation  into  the  queue.  Each  is  given  a  default  value  and  an 
update  time  of  0.  This  simulates  the  circuit  being  “switched”  on  for  the  first  time.  For  subsequent 
invocations  of  the  simulator,  the  input  signals  to  the  system  are  placed  in  the  queue.  After  the 
queue  is  initialized,  execution  continues  into  the  main  loop. 

The  VHDL  main  loop  first  updates  the  system  clock  to  the  value  of  the  top  record  in  the 
queue.  Then  all  records  that  have  this  new  time  are  collected.  For  each  of  these  records  the  new 
signal  value  is  compared  to  the  current  value.  If  the  values  are  different,  the  simulator  determines 
which  behavior  instances  are  connected  to  the  signal.  The  signal  value  is  then  changed  to  its  new 
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value.  If  they  are  equal,  the  behavior  instances  connected  to  this  signal  perceive  no  change,  and  do 
not  need  to  be  updated. 

After  all  the  records  at  the  new  time  have  been  processed,  the  simulator  updates  the  affected 
behavior  instances.  Since  there  rhay  be  many  separate  instances  that  all  refer  to  same  process  code, 
the  simulator  must  first  determine  which  process  to  execute.  The  process  contains  instructions  on 
how  to  simulate  the  process’s  behavior.  During  execution  of  the  process,  new  values  may  be  placed 
on  output  signals.  The  process  execution  module  creates  a  new  activation  record  for  the  signal  and 
places  it  on  the  queue. 

After  all  the  affected  behavior  instances  have  been  updated,  the  simulator  loops  until  the 
queue  is  empty.  This  signifies  that  the  circuit  has  reached  a  stable  state.  The  output  values  can 
then  be  checked. 

S.2.S  Diagnostic  Routines  The  diagnostic  routines  are  divided  into  four  sections.  While 
parsing  the  source  code,  a  module  generates  fault  hypotheses  for  the  processes.  Another  module 
generates  suspected  bad  components  based  on  comparing  the  simulated  outputs  with  the  actual 
outputs.  A  third  section  determines  which  hypothesis  to  use  for  the  suspect.  Finally,  there  is  a 
section  to  re-simulate  the  circuit  and  determine  if  the  hypothesis  for  the  suspect  is  valid. 

This  research  effort  used  the  Scarl’s  “Full  Consistency”  algorithm  as  modified  by  Dries.  One 
goal  of  this  effort  was  to  make  Calvin  modular  enough  so  that  the  various  modules  could  be 
upgraded  or  replaced  as  needed.  To  do  this,  the  diagnostic  modules  were  written  as  loosely  coupled 
modules.  There  is  little  or  no  parameter  passing  between  them,  other  than  the  values  of  the  input 
and  output  signals. 

3.2.3. 1  Hypothesis  Generation  Fault  hypotheses  are  generated  during  the  parsing  of 
the  VHDL  code.  After  each  VHDL  process  is  created  from  the  source  code,  the  parser  calls  the 
fault  hypothesis  module.  This  takes  the  current  process  and  generates  possible  faulty  behaviors  for 
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the  process.  The  faults  are  predetermined  by  Calvin.  Calvin  generates  faults  for  each  output  stuck 
high,  each  output  stuck  low,  each  input  stuck  high,  and  each  input  stuck  low.  Only  one  fault  at  a 
time  is  allowed  in  the  circuit. 

3.2.5.2  Suspect  Collection  Suspect  components  are  those  that  can  affect  the  reading  of 
the  sensor  that  differed  from  the  simulated  circuit.  This  limits  the  suspects  to  those  that  directly 
or  indirectly  drive  the  sensor.  In  Dries’  and  Scarl’s  algorithms,  this  is  done  by  collecting  each 
component  upstream  starting  from  the  faulty  sensor.  In  this  research  this  is  done  with  a  simple 
depth-first  search,  starting  with  the  faulty  output. 

3. 2. 3. 3  Fault  Generation  After  the  possible  suspects  have  been  identified,  it  is  the 
job  of  this  module  to  “break”  the  test  circuit.  The  collect  suspects  module  creates  a  queue  that 
contains  all  the  possible  suspects  that  could  be  the  cause  of  the  fault.  The  fault  generating  module 
takes  the  suspect  at  the  front  of  the  queue  and  causes  it  to  break.  It  iterates  through  each  fault 
hypothesis  generated  during  the  parse.  After  the  re-simulation,  the  outputs  of  the  simulated  faulty 
circuit  are  again  compared  with  those  supplied  from  the  “real  world.”  If  they  match,  the  candidate 
hypothesis  is  kept.  If  not,  the  candidate  is  rejected. 

3.2. 3. 4  Re-simulation  After  a  possible  fault  hypothesis  is  selected,  the  circuit  must 
be  re-simulated.  The  fault  generating  module  rearranges  the  pointers  to  the  process  code  blocks, 
and  re-initializes  the  simulator  variables.  This  allows  the  same  VHDL  simulator  that  generated  the 
results  for  correct  operation  also  to  be  used  for  the  simulation  of  the  faulty  circuit. 

3.3  Implementation 

3.3.1  Selection  of  a  Programming  Language  Since  I  had  decided  on  an  object-oriented  ap¬ 
proach,  the  programming  language  must  be  able  to  support  object-oriented  programming.  The 
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language  must  be  powerful  enough  to  accomplish  the  task.  I  must  also  be  able  to  use  the  language. 
Some  criteria  for  the  language  are: 

•  Object  Oriented 

As  described  above,  several  pairts  of  Calvin  are  inherently  object-oriented.  An  object-oriented 
approach  also  makes  information  hiding  and  modularity  easier.  Since  the  only  way  to  access 
or  change  the  hidden  information  is  to  use  explicit  calls  to  an  access  function,  it  is  easier  to  find 
logic  errors  in  the  program.  This  also  prevents  inadvertent  tampering  with  the  information. 

Certain  aspects  of  the  object-oriented  paradigm  were  not  initially  thought  to  be  necessary. 
These  included  the  concept  of  inheritance.  It  wzis  later  found  that  inheritance  could  be  used 
in  the  parser,  simplifying  and  standardizing  the  data  structures  greatly. 

•  Ease  of  Prototyping 

Since  most  of  the  code  was  to  be  generated  from  scratch,  several  false  starts  were  anticipated. 
Code  must  be  easily  and  quickly  written,  without  having  small  changes  requiring  missive 
rewrites.  Some  data  must  be  able  to  move  through  the  system  without  having  to  worry 
about  type-casts.  This  feature  can  have  some  disadvantages:  this  type  of  programming  can 
lead  to  poorly-written  code  that  may  lead  to  recoding  complications  and  hard-to-find  bugs. 

•  Convenient  Development  System 

The  language  should  have  a  complete  set  of  development  tools.  Although  this  does  not  nec¬ 
essarily  mean  an  integrated  development  environment,  the  basic  tools  for  editing,  compiling, 
running,  and  debugging  should  be  present  and  work  together  smoothly.  For  accessibility, 
some  or  most  of  the  code  should  be  able  to  be  developed  on  a  MS-DOS  based  machine. 

•  Compatibility  with  LEX/YACC 

As  discussed  later,  a  grammar  for  the  VHDL  parser  was  obtained  from  the  University  of 
Cincinnati.  This  grammar  was  written  in  Bison,  a  GNU  version  of  the  UNIX  utility  YACC. 
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Bison  is  the  GNU  version  of  the  UNIX  utility  YACC  (Yet  Another  Compiler-Compiler). 
These  programs  take  a  language  grammar  and  generate  C  code  that  parses  that  language. 
The  C  code  is  then  compiled  and  linked  with  the  rest  of  the  program.  The  main  advantage 
of  Bison  over  YACC  is  that  it  allows  larger  language  grammars  to  be  parsed. 

Bison  and  YACC  work  with  another  utility,  LEX.  LEX  takes  a  description  of  the  tokens 
recognized  by  a  language,  and  generates  C  code  that  parses  these  tokens.  The  source  files  for 
both  LEX  and  Bison  contain  embedded  C  code  that  is  inserted  into  the  output  files.  This 
code  determines  the  actions  that  take  place  when  certain  keywords  or  structures  have  been 
parsed.  By  using  Bison  and  LEX  with  the  VHDL  grammar  from  the  University  of  Cincinnati, 
I  did  not  have  to  write  the  actual  parser.  My  task  was  limited  to  adding  the  actions  to  take 
place  one  certain  VHDL  constructs  were  recognized. 

The  system  must  be  able  to  take  the  output  code  files  from  Bison  and  LEX  and  link  them  into 
the  simulator/diagnostic  routines.  Alternatively,  a  separate  program  could  be  written  that 
would  parse  the  VHDL  source  and  pass  the  resulting  information  to  the  rest  of  the  system 
through  a  file.  In  any  case,  some  code  would  have  to  be  written  using  the  C  language  (note 
that  this  turned  out  to  be  not  quite  true;  A  GNU  version  of  LEX,  FLEX,  was  modified  to 
use  C-l— t-). 

•  Familiarity 

Last,  but  definitely  important,  the  programmer  must  be  familiar  with  the  language.  Time 
spent  learning  a  new  language  is  time  that  could  not  be  used  on  the  research  effort. 

Initial  candidates  for  the  programming  language  were  Ada,  C/C+-I-,  LISP,  and  PC-Scheme. 
A  discussion  of  these  languages  considering  the  above  criteria  follows; 

•  Ada 
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This  language  is  the  DOD  standard  language  for  new  programming  efforts  (2:8).  Although 
some  claim  it  is  an  object-oriented  language,  there  is  some  debate.  It  does  not  support 
inheritance,  but  as  noted,  inheritance  was  not  thought  to  be  important  in  this  effort.  It  does 
have  good  support  for  modularity  and  information  hiding,  the  desired  object-oriented  features 
most  needed  for  this  effort.  A  main  feature  of  Ada  is  enforcing  type-checking.  Although  this 
can  lead  to  more  reliable  code,  it  can  hamper  prototyping  efforts.  The  type-checking  makes 
it  possible  to  catch  logic  errors  earlier  in  the  development  process.  A  more  serious  problem 
is  its  efficiency.  Ada  does  run  on  MS-DOS  platforms;  however,  the  edit/compile/run  cycles 
tend  to  be  a  lot  longer  then  those  of  the  other  languages.  Ada  does  have  methods  for  linking 
in  modules  from  other  languages,  so  it  should  be  compatible  with  LEX/YACC.  Ada’s  syntax, 
being  based  on  Pascal,  is  not  greatly  different  from  other  common  programming  languages. 

•  LISP 

This  language  is  very  much  associated  with  artificial  intelligence  research.  In  contrast  to  Ada, 
LISP  has  very  little  type-checking.  It  also  provides  a  high  level  of  abstraction  not  found  in 
“lower-level”  languages  such  as  C.  It  tends  to  be  more  compact  than  equivalent  programs  in 
other  languages.’ Features  such  as  not  having  to  declare  variables  until  they  are  used  for  the 
first  time  allow  very  rapid  programming.  Although  LISP  is  not  object-oriented  by  itself,  the 
Flavors  extensions  add  this  capability  to  LISP.  A  major  problem  with  LISP  is  the  size  of  the 
language;  it  does  not  fit  well  on  a  MS-DOS  platform.  Programming  in  LISP  also  requires  a 
different  mind-set  than  more  traditional  languages. 

•  PC-Scheme 

PC-Scheme  is  a  variation  of  LISP  that  runs  on  MS-DOS  machines.  It  has  the  same  pro¬ 
gramming  style  as  LISP,  allowing  rapid  prototyping  and  smaller  programs.  It  comes  with  a 
well-integrated  environment  for  programming  in  PC-Scheme.  It  also  has  hooks  for  integrating 
outside  code  modules. 
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•  C/C++ 


C  is  sometimes  referred  to  as  a  “low-level”  programming  language.  It  is  a  powerful,  but 
dangerous  language.  Like  machine  language,  C  assumes  the  programmer  knows  what  he  is 
doing,  even  when  he  doesn’t.  Examples  include  lack  of  bounds  checking  on  arrays,  and  little 
type  checking  on  parameters.  Unless  care  is  taken,  this  can  result  in  obscure  bugs  that  can 
affect  areas  of  the  code  far  away  from  the  original  problem.  C  itself  is  not  object-oriented, 
although  object-oriented  techniques  can  be  used. 

C++  is  a  superset  of  the  C  language  that  adds  several  features,  such  as  object-oriented 
structures.  Although  the  programmer  can  still  cause  obscure  bugs,  C++  has  several  features 
that  tend  to  catch  problems  earlier  during  development.  These  include  function  prototypes 
and  type-safe  linkage,  which  specify  function  parameter  types  and  return  values. 

C/C++  is  available  on  a  wide  selection  of  platforms,  including  both  the  Sun  Spaircstations 
and  MS-DOS  machines.  The  UNIX  operating  system  includes  many  tools  for  using  C-based 
projects.  There  are  also  good  development  systems  for  MS-DOS  platforms,  such  as  those 
by  Borland  and  Microsoft.  Another  advantage  is  that  the  output  of  Bison  and  LEX  are 
C  source  code  files.  By  using  C  or  C++  integration  of  the  various  parts  of  Calvin  would 
be  much  simpler,  without  any  concerns  about  cross-language  interfaces.  Finally,  I  have  had 
much  experience  in  C  programming,  as  well  as  some  with  C++. 

After  evaluating  the  languages,  the  initial  selection  was  to  use  C++  for  the  simulator  and  C 
for  the  parser.  The  simulator  was  the  most  object-oriented,  and  would  be  best  written  in  a  language 
that  supported  such  constructs.  Since  the  output  of  Bison  and  LEX  were  C  files,  it  was  thought 
that  the  supporting  modules  for  the  parser  also  should  be  written  in  C  for  ease  of  integration.  The 
diagnostic  functions  were  rather  loosely  coupled  to  the  rest  of  Calvin.  C++  was  chosen  for  these 
functions  to  take  advantage  of  the  additional  power  and  type-checking  features  of  C++. 
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The  initial  configuration  was  a  parser  module  separate  from  the  rest  of  the  system.  This 
would  be  run  on  a  UNIX  system  using  GNU  Bison  and  standard  UNIX  LEX.  The  rest  of  Calvin 
would  be  developed  on  a  MS-DOS  machine  using  the  Borland  C-(-+  3.0  development  system.  The 
Borland  environment  contained  both  an  ANSI  standard  C  compiler  and  version  2.1  of  C-f-+,  which 
included  templates  (the  equivalent  of  the  Ada  Generic  structure)(15:33).  It  also  came  with  libraries 
for  container  classes.  Familiarity  with  Borland  products  also  resulted  in  a  shallow  learning  curve, 
allowing  more  time  for  development. 

During  development  a  copy  of  Bison  was  found  for  MS-DOS  machines.  After  finding  that  is 
was  functionally  equivalent  to  the  version  running  on  the  UNIX  system,  the  Bison  code  was  ported 
to  the  MS-DOS  platform.  A  GNU  version  of  LEX,  called  FLEX,  was  also  found  that  would  run 
on  MS-DOS  machines.  At  this  time,  all  code  was  ported  to  the  MS-DOS  platform,  with  the  parser 
being  compiled  in  C  and  the  rest  of  Calvin  in  C++.  By  modifying  the  skeleton  file  for  Bison,  the 
output  source  files  could  be  compiled  by  the  Borland  C++  compiler.  Now,  all  the  source  files  could 
be  compiled  by  one  compiler  into  one  program.  By  doing  this,  integrating  the  various  modules 
became  trivial.  An  additional  benefit  was  allowing  C++  functionality  in  the  parser  section. 

3.3.2  Implementation  Details  The  following  sections  describe  how  Calvin  was  implemented. 
As  described  previously,  Calvin  can  be  split  into  three  main  areas:  the  VHDL  parser,  the  simulator, 
and  the  diagnostic  routines.  Calvin  was  designed  so  that  the  three  areas  are  relatively  independent 
of  each  other  and  can  be  easily  expanded. 

A  full-adder  circuit  is  used  as  an  example  throughout  this  section.  Figure  14  shows  a  schematic 
for  the  full-adder.  This  example  was  taken  from  VHDL:  Hardware  Description  and  Design  (12:18- 
22) 

The  source  consists  of  descriptions  for  an  OR  gate,  a  half-adder,  and  the  full-adder.  The 
VHDL  source  code  for  the  full-adder  is  contained  in  Appendix  B.l. 


39 


1054 


Figure  14.  Full-adder  Schematic 


3.3.3  VHDL  Parser 

3.3.3.  J  Introduction  The  parser  was  built  around  a  VHDL  grammar  written  for  the 
Bison  compiler-compiler.  As  the  VHDL  source  file  was  parsed,  several  data  structures  were  built 
that  represent  the  source  code.  This  was  done  by  embedding  in  the  Bison  grammar  file  calls  to 
outside  modules  that  build  the  data  structure  as  the  various  VHDL  constructs  were  parsed.  At 
the  end  of  the  VHDL  source  file  were  configuration  statements.  These  were  handled  by  embedding 
calls  in  the  Bison  grammar  to  call  routines  to  build  up  the  simulator  objects.  When  the  end  of  file 
was  reached,  the  parser  surrendered  control  back  to  system. 

3. 3. 3. 2  Bison  Code  The  University  of  Cincinnati  VHDL  grammar  was  for  the  IEEE- 
1076  specification  of  the  VHDL  language,  with  a  few  modifications.  These  were  done  so  that 
Bison  could  generate  a  parser  for  the  language.  Bison  generated  a  LALR(l)  parser,  which  could 
not  parse  the  entire  VHDL  language  as  described  by  the  IEEE  specification.  These  modifications 
are  summarized  in  the  header  to  the  Bison  code,  which  is  in  the  file  UV,  in  Appendix  D.l.  The 
original  code  had  three  shift/reduce  conflicts  and  three  reduce/reduce  conflicts.  Since  signal  types 
in  Calvin  were  limited  to  type  BIT,  the  number  of  shift/reduce  conflicts  was  reduced  to  two  and 
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reduce/  reduce  conflicts  to  one.  These  modifications  are  documented  in  the  part  of  the  grammar 
that  parses  the  VHDL  Type  token. 

As  the  VHDL  source  was  parsed,  an  internal  representation  was  built.  As  each  VHDL  con¬ 
struct  was  recognized,  the  relevant  information  was  stored  in  that  representation.  There  was  a 
module  that  maintained  the  current  information  for  each  VHDL  construct.  This  was  kept  in  dy¬ 
namic  memory.  When  the  parser  recognized  the  start  of  the  construct,  the  current  information 
was  set  to  a  default  state.  As  the  construct  was  parsed,  the  parser  called  functions  that  added 
the  newly  acquired  information  to  the  current  construct.  After  the  parsing  of  the  construct  was 
finished,  a  pointer  to  the  finished  construct  was  passed  back,  usually  to  a  field  within  a  higher-order 
construct.  Some  constructs,  such  as  signal  and  port  lists,  were  passed  as  linked-lists. 

Figure  15  shows  an  example  entity  description  for  an  OR-gate.  After  the  parser  found  the  is 
keyword,  the  grammar  dictated  that  a  port  clause  would  follow.  A  call  was  made  to  port.clear()  to 
initialize  the  current  port  data  structure.  The  keyword  port  and  the  “(”  token  were  then  recognized. 
The  parser  then  looked  for  a  formal  port  list.  This  consisted  of  an  identifier  list  “ill”,  colon  token, 
a  direction  (in  or  out),  and  a  signal  type  (bit).  These  values  were  placed  in  the  appropriate  fields 
within  the  port  data  structure.  The  parser  then  looked  for  the  “)”  and  tokens.  At  this  point 
the  port  data  structure  was  complete.  A  pointer  within  the  module  tasked  with  constructing  this 
structure  pointed  to  the  memory  block  that  contained  the  information.  The  parser  then  called 
a  function  that  took  this  pointer  and  placed  it  within  the  current  entity  data  structure.  This 
continued  until  all  the  VHDL  source  had  been  parsed. 

S.3.3.S  FLEX  Code  The  parser  generated  by  Bison  required  a  module  to  recognize 
the  tokens  and  keywords  in  the  source  file.  This  module  was  generated  by  a  lexical  analyzer, 
FLEX.  FLEX  was  a  GNU  version  of  the  standard  LEX  program  present  in  most  UNIX  systems. 
For  the  purposes  of  this  research  the  two  were  equivalent.  The  chief  advantage  of  FLEX  was  that 
there  was  a  version  that  runs  on  MS-DOS  machines.  A  few  modifications  had  to  be  made  so  that 
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entity  il5  is  . 
port( 

ill;  in  bit; 
il2:  in  bit; 
il3;  out  bit 


); 

end; 


Figure  15.  OR-gate  Entity  Description 


Identifiers 

Identifier  must  be  the  letter  I  followed  by 

a  three  digit  number  (1002, 1234) 

Integers 

Sequence  of  digits 

Reals 

Not  permitted 

Figure  16.  FLEX  VHDL  Limitations 


Borland  C++  could  compile  the  output  file  from  FLEX.  These  modifications  are  summarized  in 
Appendix  C. 

T1  ’  input  file  to  FLEX  described  how  the  tokens  of  the  grammar  were  to  be  recognized.  Also 
included  were  the  keywords  and  tokens  for  the  VHDL  grammar.  The  tokens  and  keywords  style 
for  VHDL  and  Ada  were  similar.  This  made  it  possible  to  take  a  LEX  file  used  in  the  CSCE663 
Compiler  Theory  and  Implementation  course  and  modify  it.  This  file  was  jointly  written  by  Captain 
Chester  A.  Wright  and  me.  The  additional  keywords  required  by  VHDL  were  added  to  this  file. 
The  file  is  named  UV.LEX,  and  is  in  Appendix  D.2. 

To  speed  development,  several  features  of  VHDL  were  restricted.  The  chief  of  these  were 
identifier  names.  Identifiers  throughout  Calvin  were  defined  as  integers.  To  make  it  easier  to  come 
up  with  the  handles,  the  VHDL  identifiers  were  defined  to  be  the  letter  ‘I’  followed  by  a  three  digit 
number.  The  features  restricted  by  the  FLEX  input  file  are  summarized  in  Figure  16. 

A  complete  description  of  the  supported  VHDL  grammar  is  given  in  Appendix  A. 


3. 3. 3. 4  Internal  Data  Structures  As  each  VHDL  construct  was  parsed,  the  necessary 
information  was  recorded  in  the  data  fields  of  a  corresponding  internal  data  structure.  As  parsing 
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continued,  the  data  structure  might  then  be  inserted  into  a  field  of  a  higher  echelon  structure.  This 
structure  could  in  turn  become  a  field  in  an  even  higher  structure.  At  the  top  of  the  hierarchy  were 
two  data  structures:  a  list  of  entity  declarations,  and  a  list  of  architecture  declarations.  Figure  17 
shows  the  complete  hierarchy  of  the  entity  declaration,  while  18  does  the  same  for  the  architecture 
structure.  The  individual  modules  that  make  up  these  hierarchies  are  in  Appendix  E.  The  names 
of  the  modules  correspond  to  the  objects  in  the  hierarchy. 

Since  this  section  was  so  tightly  bound  to  the  Bison  module  for  the  parser,  it  was  originally 
written  in  straight  C  code  using  an  object  oriented  style.  At  the  time  it  was  originally  written, 
the  GNU  Bison  was  being  used  to  generate  C  code.  It  wjis  later  ported  to  a  MS-DOS  system  and 
compiled  with  the  sameXH-l— I-  compiler  as  the  rest  of  Calvin.  Unfortunately  time  did  not  allow  this 
module  to  be  rewritten  in  straight  C-l— 1-  code.  This  would  have  resulted  in  more  consistent  data 
structures,  resulting  in  more  robust  code  that  is  easier  to  modify  (and  debug!). 

Since  an  object-oriented  approach  was  used  for  the  data  structures  and  associated  functions, 
each  of  them  tended  to  have  the  same  structure.  The  routines  for  each  structure  were  collected  into 
a  single  module,  separate  from  any  other  structure.  The  actual  data  structure  itself  was  stored  in 
the  heap  memory.  Each  module  contained  an  internal  pointer  that  pointed  to  a  current  instance 
of  the  structure.  This  structure,  known  cis  the  current  structure,  was  the  one  that  was  currently 
being  parsed. 

Each  structure  had  a  clear  routine:  this  initialized  the  internal  variables  and  set  the  internal 
structure  pointer  to  NULL.  For  list-type  structures  there  was  a  routine  to  create  a  new  object  and 
add  it  to  the  front  of  the  internal  list.  Ne.xt,  there  were  a  set  of  functions  that  added  the  values  to 
the  structure.  These  functions  were  called  by  the  parser  as  the  appropriate  value  was  determined. 
Sometimes  these  functions  added  pointers  to  other  data  structures;  other  times  a  value  was  added 
to  the  field.  After  the  object  had  been  parsed,  there  must  be  some  way  for  the  outside  program  to 
use  the  structure.  Another  function  handled  this  task  by  returning  the  address  of  the  current  data 
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Figure  17.  Entity  Hierarchy 


structure.  Usually  this  was  inserted  into  a  data  field  of  another  data  structure  by  corresponding 
functions  in  the  higher  structure.  Finally,  there  were  print  functions  that  printed  out  the  values 
of  a  data  structure.  One  function  displayed  the  current  structure,  while  another  described  the  one 
passed  by  a  pointer  reference. 


S.3.3.5  Translation  to  Simulator  Data  Structures  The  parser  translated  the  internal 
representation  of  the  source  code  into  class  instances  usable  by  the  simulator  when  it  parsed  the 
VHDL  configuration  statements.  In  this  effort,  the  configuration  source  must  come  at  the  end  of  the 
source  file,  after  all  the  architecture  and  entity  declarations  have  been  parsed.  As  the  configuration 
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information  was  parsed,  Calvin  generated  the  simulator  objects.  The  information  given  in  the 
configuration  section  determined  the  construction  of  these  objects. 

3.S.4  VHDL  Simulator 

5.3.4.1  Introduction  This  section  describes  the  VHDL  simulator  section  of  the  Calvin. 
The  flow  of  the  simulator  is  first  described,  followed  by  a  discussion  of  each  of  the  main  C++  classes 
used  to  implement  the  simulator. 

3. 3. 4. 2  Overall  Flow  The  structure  of  the  simulator  is  shown  in  Figure  19.  These 
functions  are  in  the  module  VHDL-CPP,  in  sections  F.21  and  F.22  in  Appendix  F.  The  simulator 
is  built  around  a  priority  queue  of  activation  records.  Each  activation  record  has  three  fields;  the 
name  of  the  signal  to  change,  the  new  value  of  the  signal,  and  when  it  is  to  be  updated.  Priority 
in  the  queue  is  based  on  the  time  stamp  of  the  activation  records,  with  earlier  times  towards  the 
front. 

The  ProcessJow_time()  function  first  sets  the  current  simulation  time  by  examining  the 
top  activation  record  on  the  queue.  All  activation  records  with  the  new  time  are  then  pulled  from 
the  queue.  As  each  record  is  removed,  the  value  of  the  signal  specified  in  the  record  is  checked 
against  its  current  value.  If  there  is  no  change,  the  activation  record  is  ignored.  If  there  is  a  change, 
the  signal’s  value  is  set  to  the  value  in  the  activation  record. 

Signals  are  connected  to  objects  that  represent  how  an  architecture  behaves.  In  Calvin, 
these  are  called  Behave  objects.  When  a  signal  changes  value,  all  Behave  objects  connected  to 
that  signal  must  be  updated  using  updateJ3ehave().  These  Behave  objects  are  specified  by  the 
signal’s  conns  list.  The  label  conns  is  the  equivalent  to  the  “conns”  that  Comeau  describes  for  the 
Intermetrics  VHDL  system.  In  the  Intermetrics  system,  “conns”  is  the  pointer  to  a  list  of  behavior 
instances  for  which  this  signal  is  an  input  (3:50).  The  identifiers  of  these  objects  are  collected  into 
a  set  object.  This  is  a  container  class  defined  in  the  Borland  library  that  allows  only  one  copy  of 
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Figure  19.  Block  Diagram  of  VHDL  Simulator 
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a  member  to  be  in  the  set.  This  keeps  the  simulator  from  updating  a  Behave  object  twice  during 
the  same  simulation  time. 

After  all  the  signals  with  the  same  simulation  time  have  been  removed  from  the  queue,  the 
simulator  updates  the  Behave  objects  that  the  changed  signals  drive.  Each  Behave  object  references 
a  Block  object.  This  object  contains  a  set  of  code  sections  that  describe  how  the  Behave  object 
works.  Then,  according  to  the  hypothesis  generated  during  the  parsing,  the  simulator  takes  one  of 
the  code  sections  from  the  block  and  executes  it. 

The  code  section  is  a  list  of  opcodes,  which  are  discussed  in  more  detail  below.  The  object  can 
pull  in  current  signal  values  through  the  input  port  list  of  the  Behave  object.  Other  opcodes  perform 
calculations.  The  simulator  handles  output  signal  values  by  posting  them  to  the  priority  queue. 
The  M_POST  opcode  specifies  the  modified  signal’s  name,  its  new  value,  and  the  propagation 
delay  of  the  block.  The  simulator  builds  an  activation  record  from  this  information  and  inserts  it 
into  the  priority  queue,  completing  the  simulation  cycle. 

Since  at  the  beginning  of  simulation  time  the  queue  is  empty,  there  must  be  some  way  to 
start  the  simulator.  The  processJnit()  function  handles  this  by  calling  update_behave()  for 
each  Behave  object  in  the  simulator.  Any  Behave  objects  that  change  a  signal  value  will  place 
an  activation  record  in  the  queue.  The  earliest  activation  record  is  then  pulled  from  the  queue, 
starting  the  simulation.  The  simulator  will  then  cycle  until  the  queue  is  empty.  This  signifies  that 
the  circuit  has  reached  a  stable  state.  If  the  circuit  has  feedback,  it  is  possible  to  design  a  circuit 
that  will  never  be  stable.  This  effort  assumes  only  feed-forward  combinatorial  circuits;  these  will 
always  reach  a  stable  state. 

3.3.4.S  Microcode  The  simulation  of  the  circuit’s  components  is  handled  by  a  “mi¬ 
crocode”  interpreter.  This  code  is  in  modules  MCODE  and  CODE,  in  Appendix  F.  Instead 
of  generating  C  source  code  like  the  Intermetrics  VHDL  system,  Calvin  generates  opcodes  for  an 
interpreted  language,  which  will  be  referred  to  in  this  thesis  as  “microcode”  or  “mcodes.’ 
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The  microcode  interpreter  is  stack-oriented  with  a  separate  set  of  registers.  This  style  was 
inspired  from  the  Hewlett-Packard  line  of  programmable  calculators,  which  I  have  used  for  several 
years.  Operands  are  pushed  onto  an  internal  stack,  which  is  then  used  by  the  operators.  An 
auxiliary  set  of  registers  can  hold  values  that  need  to  be  saved  from  change.  A  more  complete 
description  of  the  opcodes  is  discussed  later. 

3. 3. 4. 4  Data  Strucirtres  To  speed  development  of  Calvin  a  “few  shortcuts”  were  taken. 
Several  places  within  the  various  objects  required  a  set  of  values.  An  attempt  at  using  the  Set 
class  supplied  by  Borland  was  unsuccessful,  so  an  array  was  used  instead.  In  most  cases,  the  object 
used  an  integer  array  along  with  an  index  variable  that  marked  the  next  empty  slot  in  the  array. 
The  length  of  the  array  was  defined  in  the  header  files  as  MAX -xxx_LEN.  Since  values  were  only 
added  to  the  array,  no  special  garbage  collection  routines  were  needed. 

As  Calvin  developed,  the  maximum  array  lengths  were  adjusted  as  needed.  This  method  of 
managing  data  collections  was  wasteful  of  memory;  howev.er,  lack  of  memory  never  was  a  problem. 

Another  shortcut  dealt  with  identifiers.  Using  proper  software  engineering  practices,  there 
should  be  a  separate  identifier  class.  To  speed  the  development  of  Calvin  all  identifiers  were  defined 
as  integers.  This  also  simplified  the  internal  operand  stack  for  simulating  the  process  code  sections. 
By  having  both  identifiers  and  signal  values  defined  as  integers,  the  stack  could  be  implemented 
as  a  simple  integer  stack.  An  alternative  would  have  been  to  create  a  new  data  object  that  would 
be  a  union  of  identifier  type  and  signal  value  that  included  a  field  determining  which  was  which. 
Implementing  future  data  types  other  than  BIT  will  require  this  approach. 

3.3.4-5  Signal  Record  Class  The  signal  object  is  used  to  connect  the  various  processes 
of  the  simulated  circuit  together.  The  module  that  defines  the  signal  object  is  module  SIGNAL, 
in  Appendix  F.  The  signal  object  in  the  simulator  is  derived  from  the  Intermetrics’  signal  record  as 
described  by  Comeau  (3:3.10).  Figure  20  describes  the  data  fields  for  the  signal  record  object.  The 
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id 

Signal  Identifier 

name[  ] 

String  name  for  signal 

cval 

Value  of  signal 

conns[  ] 

Behave  instances  connected  to  this  signal 

last.conn 

Last  conns 

driver.bi 

Behave  instance  that  drives  this  signal 

Figure  20.  Data  Fields  for  SignalRecord  Object 


SignalRecord 

Constructor 

get.id 

Return  signal  identifier 

print 

Print  signal  record  (debugging  function) 

add.conns 

Add  behave  instance  to  conns  list 

get.conns 

Return  pointers  to  conns  list 

set.cval 

Set  signal  value 

get.cval 

Get  current  signal  value 

set.driver.bi 

Set  driving  behave  instance 

get.driver.bi 

Get  driving  behave  instance 

Figure  21.  Functions  for  SignalRecord  Object 


ID  field  uniquely  identifies  the  signal  in  the  circuit.  The  name  field  is  used  for  the  user  interface. 
The  current  value  of  the  signal  is  maintained  by  the  cval  field.  The  list  of  behave  instances  that 
are  driven  by  the  signal  is  kept  in  the  conns  array.  These  instances  are  those  that  will  be  updated 
whenever  the  value  in  cval  is  changed  by  a  record  being  de-queued  from  the  activation  record 
queue,  last.conn  is  an  index  into  the  conns  array.  It  points  to  the  next  available  slot  in  that 
array.  Finally,  driver _bi  is  the  identifier  of  the  behave  instance  that  drives  the  signal. 

A  list  of  functions  available  for  the  SignalRecord  object  is  in  Figure  21.  Like  most  objects,  the 
ID  of  the  signal  can  be  obtained  by  calling  get  Jd().  The  functions  add-conns()  and  get-conns() 
allow  access  to  the  list  of  Behave  objects  connected  to  the  signal.  The  value  of  the  signal  is  set 
by  set_cval(),  and  obtained  by  get_cval().  Access  to  the  name  of  the  Behave  object  that  drives 
the  signal  is  through  set^river_bi()  and  get_driver_bi().  For  debugging,  print()  was  written 
to  display  the  data  within  the  signal  object. 


3.S.4-6  Behavior  Instance  Class  When  the  VHDL  simulator  changes  the  value  of  a 
signal,  that  signal  returns  a  set  of  circuit  components  that  must  be  updated.  Each  of  these  com- 
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id 

Behave  identifier 

blockJd 

Block  associated  with  this  behave 

code-select 

Current  hypothesis  in  use  for  simulation 

input[  ] 

List  of  signals  tied  to  behave  inputs 

lastJn 

Last  input  added 

output[  ] 

List  of  signals  ties  to  behave  outputs 

last.out 

Last  output  added 

Figure  22.  Data  Fields  for  Behave  Object 


ponents  is  simulated  by  a  Behave  object.  The  source  code  for  these  objects  is  in  the  module 
BEHAVE,  in  Appendix  F. 

The  private  data  fields  in  the  Behave  object  are  shown  in  Figure  22.  As  in  most  objects,  the 
Behave  object  contains  an  identifier  id.  Each  Behave  object  also  contains  a  set  of  input  signals  and 
a  set  of  output  signals.  In  Figure  22  these  are  the  fields  mput[  ],  last  Jn  and  output[  ],  last^ut. 

The  code  for  simulating  the  Behave  object  is  contained  within  a  separate  Block  object.  The 
block  object  is  defined  in  the  BLOCK  module  in  Appendix  F.  The  ID  of  the  Block  object  is 
kept  in  blockJd  field.  Codejselect  determines  which  code  selection  to  simulate  in  the  Block  object. 
This  field  is  kept  within  the  Behave  object  since  there  might  be  many  instances  referring  to  the 
same  Block  object,  each  selecting  its  own  code. 

The  purpose  of  having  both  Block  and  Behave  objects  was  efficiency.  In  VHDL  there  can 
be  several  instantiations  of  the  same  object.  An  example  is  an  adder  constructed  with  two  XOR 
gates.  When  the  XOR  gate  is  defined  in  the  source,  a  Block  object  is  created  to  allow  an  XOR 
gate  to  be  simulated.  To  avoid  duplicating  the  Block  for  both  XOR  gates  in  the  full  adder,  two 
Behave  objects  are  created  instead.  Each  of  the  Behave  objects  points  to  the  XOR  block  with 
the  Behave  object’s  block  Jd  field.  Although  the  code  section  for  XOR  might  not  be  long  enough 
to  justify  breaking  it  out  of  the  Behave  object,  other  objects  might  be.  This  is  especially  true 
once  the  various  fault  hypotheses  are  included. 

A  list  of  routines  that  can  be  used  on  Behave  objects  is  shown  as  Figure  23.  There  are 
two  constructor  functions.  Both  reset  the  indexes  for  the  input  signal  and  output  signal  arrays. 
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Behave 

Constructor 

getJd 

Return  Behave  identifier 

set-codejselect 

Select  code  for  execution 

get.current_select 

Get  current  code  select 

set-blockJd 

Set  block  identifier 

get-block-id 

Get  block  identifier 

get-code-count 

Get  number  of  hypothesis 

addJnput 

Add  signal  to  input  of  Behave 

getJnput 

Get  ID  of  signal  tied  to  input 

getJnput-count 

Get  number  of  input  signals 

addjoutput 

Add  signal  to  output  of  Behave 

get-output 

Get  ID  of  signal  tied  to  output 

get-output-count 

Get  number  of  output  signals 

print 

Print  Behave  (debugging  function) 

Figure  23.  Functions  for  Behave  Object 


In  addition,  one  constructor  allows  the  ID  of  the  block  to  be  set.  The  other  constructor  lacks 
parameters;  this  is  required  by  C++  for  creating  an  array  of  these  objects. 

The  Behave  objects  include  several  access  functions.  The  function  get  Jd()  returns  the  ID  of 
the  object.  To  hypothesize  faults,  or  to  use  the  correct,  behavior  requires  a  call  to  set_code_select(). 
Passing  a  value  of  0  to  the  object  through  this  function  allows  the  component  to  be  simulated  cor¬ 
rectly  (no  faults).  The  current  fault  number  is  obtained  by  sending  the  block  object  get  .cur  rent  jselect. 
To  determine  which  Block  object  is  to  be  executed  for  the  Behave  object,  the  simulator  calls 
getT)lock_id() . 

A  group  of  three  functions  handles  access  to  the  input  signals  for  the  object.  The  parser 
calls  addJnput()  to  add  a  new  signal  to  the  Behave  object.  To  get  the  ID  of  an  input  sig¬ 
nal,  the  simulator  calls  get  Jnput.  Finally,  the  current  number  of  input  signals  is  obtmned  via 
get -input -count().  A  similar  set  of  functions  handles  the  output  signals.  Finally,  for  debugging 
purposes,  a  print  function  prints  a  description  of  the  Behave  object. 


3.3.4.!  Block  class  The  purpose  of  the  Block  class  of  objects  is  to  hold  references  to 
the  various  code  sections  that  could  be  run  to  simulate  a  particular  VHDL  architecture.  The  source 
code  for  this  object  is  in  module  BLOCK,  in  Appendix  F.  These  are  kept  as  an  array  within  the 
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id 

Behave  identifier 

sim-codeJdQ 

list  of  code  ID’s  for  this  block  (process) 

last-code-no 

Last  code  number 

Figure  24.  Data  Fields  for  Block  Object 


block 

Constructor 

get-id 

Get  block  identifier 

add.code 

Add  new  process  code  ID  to  code  list 

get-code 

Get  code  ID  from  code  list 

get-code_count 

Get  number  of  hypotheses  in  this  block 

Figure  25.  Functions  for  Block  Object 


Block  object.  In  all  cases  the  code  section  that  simulates  correct  operation  of  the  architecture  is 
in  position  0.  Figure  24  contains  a  complete  list  of  the  private  data  fields  within  the  Block  object. 

The  functions  available  to  the  Block  object  include  a  constructor,  a  function  for  returning  the 
Block’s  ID,  and  functions  for  adding  and  retrieving  the  code  section  ID’s.  A  full  list  of  functions 
is  listed  in  Figure  25. 


3.3. 4-8  Code  Class  Each  Block  object  contains  at  least  one  code  object  for  simulating 
the  operation  of  the  architecture.  The  code  object  is  defined  in  the  CODE  module,  in  Appendix 
F.  The  code  object  can  be  thought  of  as  a  “program”  for  simulating  a  process.  It  contains  an  ID 
to  allow  it  to  be  referenced  by  the  appropriate  Block.  The  “program”  is  stored  as  an  array  of 
MCode  objects,  which  are  described  later.  Figure  26  contains  a  list  of  the  data  fields  within  the 
Code  object. 

The  functions  available  for  the  Code  object,  which  are  summarized  in  Figure  27,  are  straight¬ 
forward.  The  getJd()  function  returns  the  Code’s  ID.  The  parser  uses  add-mcode()  while 
creating  the  process  block.  The  code  is  simulated  by  calling  the  execute()  function.  A  debugging 
function  print ()  lists  the  program  to  the  screen. 


id 

Code  identifier 

code.blkQ 

Program  storage 

last.code.jio 

Next  available  line  in  program  storage 

Figure  26.  Data  Fields  for  Code  Object 
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getJd 

Get  identifier  for  code 

addjncode 

Add  new  mcode  to  program 

execute 

Execute  program 

print 

Print  program  (debugging  function) 

Figure  27.  Functions  for  Code  Object 


M-NULL 

Null  opcode 

M.GET 

Get  signal  (signal  no.) 

MJOST 

Post  signal  (signal  no.,  value,  delay  time) 

M-PUSH 

Push 

MJJOT 

NOT  (value) 

M-AND 

AND  (valuel,  value2) 

M.OR 

OR  (valuel,  value2) 

M-XOR 

XOR  (valuel,  value2) 

M_END 

End  execution 

M_NAND 

NAND  (valuel,  value2) 

M.NOR 

NOR  (valuel,  value2) 

MJOP 

Pop  (and  discard)  value  on  top  of  stack 

MJSTORE 

Store  (addr)  value  into  register 

MJIETRV 

Retrieve  (addr)  value  from  register 

Figure  28.  MCode  Op  Codes 


3. 3.4-9  MCode  class  The  purpose  of  this  class  is  to  gather  all  the  available  operations 
together.  The  only  data  field  is  the  opcode.  The  opcodes  are  defined  in  the  header  file  for  the  class. 
A  list  of  them  is  shown  in  Figure  28.  The  complete  class  definition  is  in  the  MCODE  module, 
listed  in  Appendix  F.  The  opcodes  are  negative  values.  If  the  simulator  encounters  a  positive  value, 
it  is  interpreted  as  data  and  pushed  onto  the  stack.  When  the  code  section  for  the  process  is 
finished,  the  M  JEND  opcode  signals  the  simulator  to  stop. 

M_NULL  is  the  equivalent  of  a  NOP.  It  was  present  for  debugging  the  simulator.  M_GET 
and  M-POST  handle  passing  signal  values  into  and  out  of  the  process.  In  both  cases  the  signal 
number  used  by  the  instruction  is  on  the  top  of  the  stack  This  number  is  an  index  into  the  input  or 
output  signal  arrays  in  the  executing  Behave  object.  M_POST  requires  two  additional  parame¬ 
ters:  the  new  value  for  the  posted  signal,  and  how  far  in  future  will  the  new  value  be  assigned  to 
the  signal. 
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MCode 

Constructor 

execute 

Execute  the  instruction 

print 

print  mnemonic  (Debugging  function) 

get-op-code 

Return  op  code 

Figure  29.  Functions  for  Code  Object 


M  J*OST  creates  an  activation  record  using  the  signal  name,  value  and  delay  time.  This 
delay  time  is  added  to  the  current  simulator  time  in  order  to  determine  were  in  the  priority  queue 
the  new  activation  record  will  be  placed. 

M_A.ND,  M_OR,  M_XOR,  M_NAND,  and  M_NOR  perform  their  named  operations 
using  the  top  two  operands  on  the  stack.  The  result  is  placed  back  on  top  of  the  stack.  M_NOT 
inverts  the  value  of  the  top  of  stack.  A  T’  value  is  changed  to  ‘0,’  while  a  ‘0’  is  changed  to  a  T.’ 

Some  hypotheses  require  an  opcode  for  ignoring  the  current  vetlue  of  a  signal.  The  M  JPOP 
opcode  handles  this  by  discarding  the  current  top  of  stack.  The  i.ew  value  can  then  be  pushed  onto 
the  stack. 

For  certain  faults,  a  value  below  the  top  of  the  stack  may  need  to  be  changed  to  reflect  a 
certain  fault.  The  top  of  the  stack  can  be  saved  and  later  restored  by  using  the  MJSTORE  and 
M_RETRV  opcodes.  These  codes  save  the  top  of  stack  in  a  specified  register.  The  top  of  stack  can 
then  be  removed,  and  the  value  below  ciianged.  These  opcodes  also  can  be  later  used  to  implement 
temporary  storage  for  other  uses  not  required  at  this  time. 

Figure  29  contains  the  list  of  functions  for  the  MCode  class.  The  execute()  function 
executes  the  instruction.  The  value  of  the  opcode  is  returned  via  get_Dp_code().  The  function 
print ()  was  used  to  debug  the  system. 

3.3.5  Diagnostic  Routine  This  routine  implements  a  version  of  Dries’  Diagnose  algorithm. 
A  flow  diagram  of  Calvin’s  implementation  is  in  Figure  30.  (This  is  the  same  diagram  as  Figure  8.) 
The  algorithm  is  contained  in  the  module  CALVIN,  listed  in  Appendix  F. 
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Diagnose 


Figure  30.  Calvin’s  Diagnostic  Algorithm 
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3.3.5. 1  Fault  Deierminaiton  During  the  diagnostic  phase  Calvin  is  given  a  list  of  input 
values  and  recorded  output  values  from  the  “outside  world.”  Calvin  sets  the  circuit’s  inputs  to  those 
supplied  and  simulates  the  circuit.  Calvin  checks  each  sensor  to  see  if  it  matches  the  recorded  value. 
If  all  match,  Calvin  declares  that  the  circuit  has  no  apparent  problems. 

3. 3. 5. 2  Collection  of  Suspects  If  an  output  value  does  not  match  the  expected  value, 
Calvin  calls  a  routine  to  collect  possible  suspects.  This  routine  takes  the  parsed  representation  of 
the  circuit  and  determines  which  component  could  affect  the  errant  output.  These  are  placed  in  a 
queue. 

Currently,  suspects  are  generated  by  using  a  depth-first  strategy.  The  component  connected 
to  the  output  is  placed  first  in  the  queue.  Then  the  collection  routine  is  called  recursively  for 
each  signal  attached  to  that  component’s  inputs.  Recursion  ends  when  it  reaches  an  input  signal. 
Although  not  very  efficient,  this  module  is  almost  totally  independent  of  the  rest  of  Calvin,  and 
can  be  easily  modified  or  replaced.  The  only  output  is  the  queue  containing  the  list  of  suspects.  It 
can  be  rewritten  without  affecting  the  rest  of  the  system. 

3. 3. 5. 3  Disproving  Hypotheses  Calvin  takes  each  suspect  from  the  queue  and  modifies 
it  according  to  the  hypotheses  generated  during  parsing.  Each  suspect  body  has  a  list  of  behaviors 
that  were  given  it  while  it  was  being  parsed.  The  fault  is  simulated  by  changing  the  active  behavior 
to  one  of  the  fault  behaviors.  Calvin  iterates  through  these  hypotheses,  re-simulating  the  circuit 
after  the  behavior  hats  been  switched.  Calvin  then  checks  all  the  simulated  outputs  against  those 
that  were  supplied.  If  they  match,  Calvin  prints  a  message  stating  the  component’s  name  and  the 
hypothesis’  name.  Calvin  then  continues  with  the  rest  of  the  hypotheses.  When  all  the  hypotheses 
are  finished  for  a  suspect  component,  the  behavior  of  that  component  is  reset  to  the  correct  behavior. 
Calvin  pulls  the  next  suspect  from  the  queue  and  the  cycle  repeats. 
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3.4  Summary 


This  chapter  gave  an  overview  of  Calvin.  This  included  the  generate  and  test  areas.  Next  was 
a  more  detailed  look  at  Calvin,  breaking  it  down  into  parsing,  simulating  and  diagnostic  routines. 
Following  this  was  a  discussion  of  the  implementation  of  Calvin.  This  included  reasons  behind  the 
languages  selected,  and  detailed  descriptions  of  the  parser,  simulator,  microcode,  data  structures 
and  diagnostic  routines.  The  source  code  for  Calvin  is  in  Appendices  D  through  F.  The  next 
chapter  will  describe  some  test  files  used,  and  will  discuss  ways  that  Calvin  can  be  improved. 
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IV.  Results 


4.1  Testing  Calvin 

Three  circuits  were  used  to  test  the  diagnostic  powers  of  Calvin.  These  were  a  full  adder,  a 
two-operation  ALU,  and  an  adder. 

Figure  31  is  the  schematic  for  the  full-adder.  The  schematic  for  the  ALU  is  Figure  32  and  for 
the  adder  is  Figure  33.  In  Figure  32  the  dashed  lines  are  the  probes  inserted  into  the  circuit.  The 
actual  VHDL  code  for  the  full-adder  is  in  Appendix  B.l,  the  ALU  without  probes  in  Appendix  B.2, 
the  ALU  with  probes  in  Appendix  B.3,  and  the  adder  in  Appendix  B.4.  Appendix  B.5  describes  a 
five-bit  two’s  compliment  ALU  that  performs  addition  and  subtraction.  This  circuit  is  not  discussed 
in  this  chapter;  it  was  included  as  another  example  that  Calvin  can  use.  To  validate  these  files,  they 
were  processed  with  the  Zycad  VHDL  system.  Since  Calvin  does  not  have  libraries  implemented, 
minor  modifications  were  made  to  the  files.  Complete  details  of  the  modifications  are  in  Appendix 
G.  Appendix  G  also  contains  the  results  from  the  Zycad  system.  The  example  circuits  performed 
as  expected. 

In  Calvin  all  VHDL  identifiers  are  limited  to  the  character  ‘I’  followed  by  a  three-digit  number. 
To  keep  track  of  the  various  components,  the  names  were  kept  consistent. 

The  single-bit  full  adder  was  used  during  development.  Although  small,  this  circuit  contained 
all  the  elements  supported  by  the  VHDL  simulator  in  Calvin. 

A  two-operation  ALU  simulated  a  system  with  multiple  independent  subsystems  that  had 
little  interaction.  The  ALU  performs  either  an  AND  or  an  OR  function  on  the  two  sets  of  inputs, 
depending  on  a  select  line.  Since  these  are  logical  functions,  the  operation  on  one  bit  does  not 
affect  any  other  bit.  The  only  area  that  affects  all  operations  is  the  select  line.  The  circuit  was 
modified  by  routing  the  internal  lines  to  outputs  (sensors). 
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The  four  bit  adder  simulated  a  system  in  which  the  subcomponents  interacted  with  each 
other.  The  adder  consisted  of  multiple  copies  of  the  original  full-adder,  with  the  carry-out  of  one 
bit  connected  to  the  carry-in  of  the  next.  A  faulty  device  will  tend  to  affect  many  sensors. 

4.1.1  Running  Calvin  This  section  discusses  how  Calvin  was  run.  First  is  a  description  of 
how  to  run  Calvin.  Then  two  examples  are  given,  the  full-adder  and  the  ALU.  In  the  examples  the 
correct  operation  of  the  circuit  is  validated.  This  is  done  by  using  sets  of  data  that  show  correct 
operation  of  the  “real”  circuit. 

Calvin  took  the  source  code  for  the  test  circuits  and  an  input  file  that  contained  test  inputs 
and  outputs  and  attempted  to  find  the  problem  (if  one  existed).  The  test  outputs  for  the  “actual” 
circuit  were  calculated  before  running  Calvin.  To  validate  correct  operation  of  Calvin,  this  was 
done  for  correct  operation  of  the  circuit  first.  Then,  Calvin  was  tested  with  errors  placed  in  the 
circuit.  The  results  of  the  errors  were  calculated  and  supplied  to  Calvin  as  the  outputs  of  the 
“actual”  circuit.  In  all  cases  Calvin  did  find  the  fault  when  the  fault  affected  a  sensor  reading. 
Unfortunately,  most  of  the  time  Calvin  also  would  find  many  other  possible  problems  that  also 
could  cause  the  same  sensor  values.  Adding  sensors  to  internal  signals  of  the  circuit  cut  down  the 
number  suspects.  In  effect  this  was  adding  probes  to  the  test  circuit. 
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Figure  32.  ALU  Schematic 
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The  user  interface  to  Calvin  was  designed  so  that  in  can  be  run  in  batch  mode.  The  user 
supplies  a  set  of  flags  (detailed  in  the  module  main.cpp),  a  source  file,  and  a  test  file.  The  output 
could  then  be  re-directed  into  a  file  and  examined.  This  allows  many  test  cases  to  be  run  at  the 
same  time.  Most  of  the  flags  determined  what  information  is  displayed.  The  others  controlled 
small  improvements  to  Calvin.  When  Calvin  determined  that  a  suspect  could  account  for  all  the 
outputs,  it  displayed  it  to  the  standard  output  device  (screen  or  redirected-output  file).  After  each 
diagnosis,  Calvin  printed  out  information  about  that  run.  This  information  included; 

•  how  many  suspect  components  that  were  collected, 

•  how  many  hypotheses  that  Calvin  generated, 

•  how  many  different  faults  that  could  cause  the  supplied  circuit’s  outputs, 

•  the  number  of  activation  records  posted  by  Calvin’s  VHDL  simulator, 

•  the  number  of  Behave  objects  that  were  updated, 

•  total  number  of  simulations  done  by  Calvin. 

Idealy,  these  numbers  should  be  as  low  as  possible.  The  first  three  numbers  determine  how 
well  Calvin  could  find  the  actual  culprit.  The  first,  the  number  of  suspects  collected,  show  how 
well  the  suspect  collection  routine  discriminated  among  the  circuit’s  components.  The  next  value, 
number  of  hypotheses  checked,  shows  how  many  hypotheses  Calvin  checked  during  the  diagnosis. 
This  higher  this  number  is,  the  more  hypothesis  Calvin  had  to  run  to  determine  if  a  suspect  could 
cause  the  reported  outputs.  The  third  number  is  how  many  hypotheses  Calvin  found  that  could 
cause  the  reported  outputs.  Since  one  assumption  was  that  there  was  only  a  single  fault,  ideally 
this  value  should  be  one.  The  last  three  numbers  give  an  idea  of  how  many  computations  that 
Calvin  must  do.  Since  these  numbers  are  closely  related  to  the  circuit’s  input  values  and  number 
of  hypotheses  that  Calvin  test,  they  are  not  important.  They  were  used  mainly  as  debugging  tools 
during  implementation. 
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For  a  detailed  example,  consider  the  Full-Adder  shown  in  Figure  31.  While  the  full-adder 
source  weis  being  parsed,  Calvin  generated  mcode-blocks  that  would  simulate  the  correctly-operating 
version  of  each  process  in  the  full-adder.  After  each  block  was  created,  it  was  sent  to  a  hypoth¬ 
esis  generating  module.  This  module  generated  additional  mcode-blocks  to  simulate  the  errors 
that  Calvin  was  programmed  to  check.  These  were  gathered  and  placed  in  a  behave  object  that 
represented  the  process.  A  sample  test  file  is  shown  in  Figure  34.  The  top  eight  lines  simulated 
correct  behavior  of  the  circuit.  The  following  lines  simulated  the  circuit  after  certain  faults  had 
been  introduced.  Calvin  was  run,  showing  the  values  Calvin  thought  should  be  at  the  output,  as 
well  as  the  possible  faults  Calvin  found.  For  the  correct  outputs,  Calvin  reported  that  its  outputs 
values  matched  those  reported.  Calvin  then  stated  that  no  errors  were  found. 

The  first  fault  introduced  was  the  output  of  1082  stuck  high.  In  this  case,  no  matter  what 
the  inputs  are,  the  carry-out  will  always  be  high.  The  first  set  of  input  had  all  inputs  low.  In  this 
case  both  outputs  also  should  be  low,  which  Calvin  also  determined.  Since  the  output  values  as 
determined  by  Calvin  did  not  match  those  supplied  by  the  test  file,  Calvin  attempted  to  find  the 
fault.  The  first  step  was  to  collect  the  possible  suspects.  Working  upstream  from  1082  (the  carry¬ 
out  OR-gate),  Calvin  determined  that  1082,  1081, 1080,  and  1080  could  be  at  fault.  The  duplicate 
1080  component  came  from  looking  at  the  inputs  of  1081  as  well  as  1082.  An  improved  routine 
that  stopped  the  depth-first  search  when  a  previously-found  suspect  was  encountered  eliminated 
the  duplicate  1080. 

Calvin  simulated  each  hypothesis  for  a  suspect  component,  starting  with  1082.  When  Calvin 
was  parsing  the  VHDL  code  for  an  OR-gate,  it  determined  that  there  were  six  possible  problems 
that  could  happen  to  the  gate;  output  number  0  stuck  high/low,  input  number  0  stuck  high/low, 
and  input  number  1  stuck  high/low.  Calvin  hypothesized  each  of  these  problems,  and  found  that 
the  following  could  cause  the  reported  values; 

•  output  #0  stuck  hi. 
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Inputs 

Outputs 

Comments 

1051 

1052 

1053 

1054 

(X) 

(Y) 

(Cin) 

(Sum) 

0 

0 

0 

0 

Correct  operation 

0 

0 

1 

1 

0 

1 

0 

1 

0 

1 

1 

0 

1 

1 

0 

0 

1 

0 

1 

0 

1 

0 

1 

1 

1 

0 

0 

1 

1 

1 

1 

1 

1 

0 

0 

0 

0 

1 

1082  Out  stuck  high 

0 

1 

1 

0 

1 

1082  Out  stuck  high 

Figure  34.  Test  Data  for  FULLADD.VHD 


Output 

#0 

stuck 

hi 

at 

00 

Input 

#0 

stuck 

hi 

at 

82 

Input 

#1 

stuck 

hi 

at 

82 

Output 

#1 

stuck 

hi 

at 

81 

Output 

#1 

stuck 

hi 

at 

80 

Figure  35.  Faults  Found  in  FULLADD.VHD  With  1082’s  Output  Tied  High 

•  input  #0  stuck  hi, 

•  input  #1  stuck  hi. 

Calvin  did  the  same  with  the  rest  of  the  suspects.  A  complete  list  of  possible  faults  Calvin  found  is 
in  Figure  35.  Note  this  does  include  the  introduced  fault,  1082  output  stuck  high.  The  half-adders 
each  had  8  hypothesis  (each  of  the  four  ports  stuck  high  and  stuck  low),  and  the  OR-gate  had  6 
(three  ports  stuck  high/low).  This  meant  Calvin  checked  a  total  of  22  hypotheses. 

In  the  next  example,  the  same  fault  (1082  output  stuck  high)  was  kept  in  the  simulated  “real” 
circuit.  But  this  time  the  inputs  were  0, 1  and  1.  Calvin  simulated  the  circuit  and  found  its  outputs 
the  same  as  those  reported  to  Calvin.  Calvin  decided  there  was  no  problem  with  the  circuit. 

A  more  complex  example  uses  the  ALU  shown  in  Figure  32.  Sample  inputs  to  the  circuit, 
along  with  the  outputs  from  a  “real”  circuit  are  in  Figure  36.  The  circuit  without  the  probes  was 
used  first.  To  do  this,  the  output  signals  1710-1712  and  1810-1812  were  commented  out,  and  internal 
signals  with  the  same  name  were  declared.  This  VHDL  code  is  in  Appendix  B.2.  Values  for  the 
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Inputs 

Outputs 

1595 

■jgnn 

511 

512 

1520 

1521 

1522 

1530 

1531 

1532 

S 

BM 

A1 

A2 

BO 

B1 

B2 

ZO 

Z1 

Z2 

0 

1 

1 

1 

1 

1 

1 

1 

1 

1 

0 

1 

1 

1 

0 

1 

1 

0 

1 

1 

1 

wm 

1 

1 

0 

1 

1 

1 

1 

1 

1 

n 

0 

0 

0 

1 

1 

1 

1 

1 

0 

0 

0 

0 

1 

1 

0 

0 

0 

0 

1 

1 

1 

1 

1 

DHI 

0 

1 

1 

Figure  36.  Test  Data  for  ALU.VHD 


Output 

#0 

stuck 

low 

at 

605 

Input 

#0 

stuck 

low 

at 

605 

Output 

#0 

stuck 

low 

at 

603 

Input 

#0 

stuck 

low 

at 

603 

Input 

#1 

stuck 

low 

at 

603 

Output 

#0 

stuck 

low 

at 

601 

Input 

#0 

stuck 

low 

at 

601 

Input 

#1 

stuck 

low 

at 

601 

Figure  37.  Faults  Found  in  ALU.VHD  With  IBOl’s  Output  Tied  Low 


correctly  working  “real”  circuit  are  at  the  top  of  the  table,  with  simulated  fault  conditions  and 
their  output  values  below.  The  first  fault  introduced  was  shorting  output  of  gate  i601  low.  With  all 
inputs  high,  and  the  AND  operation  selected,  Calvin  determined  that  all  the  outputs  also  should 
have  been  high.  Comparing  against  those  supplied  by  the  “real”  circuit,  Calvin  found  one  of  the 
components  tied  to  the  1530  output  was  at  fault.  The  suspects  were  1605,  1604,  1603,  1606,  1602, 
and  1601.  Since  none  of  the  other  components  affect  the  output  1503,  Calvin  did  not  hypothesize 
any  of  others.  After  checking  out  all  the  hypotheses  for  the  1601-1606,  Calvin  came  up  with  a  list 
of  possible  suspects.  These  are  in  Figure  37.  Calvin  did  find  the  fault,  1601 ’s  output  stuck  low, 
although  it  also  came  up  with  seven  others. 

This  case  was  re-run  using  the  ALU  circuit  with  probes  (Appendix  B.3).  The  same  inputs 
and  outputs  were  used,  with  the  additional  values  for  the  probes  supplied.  These  values  are  in 
Figure  38.  With  the  additional  information,  Calvin  was  able  to  narrow  it  down  to  three  suspects, 
which  are  listed  in  Figure  39.  Since  1710  along  with  1530  was  low,  the  hypotheses  for  1603  and  1605 
were  ruled  out.  No  hypothesis  for  these  components  could  account  for  the  ‘1’  value  at  1710. 
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Inputs 

1  Outputs 

1595 

1510 

511 

512 

1520 

1521 

1522 

1530 

1531 

1810 

1711 

1811 

1712 

1812 

S 

AO 

A1 

A2 

BO 

B1 

B2 

ZO 

Z1 

YOO 

YAl 

YOl 

YA2 

Y02 

0 

1 

1 

1 

1 

1 

1 

0 

1 

1 

0 

1 

1 

1 

1 

1 

Figure  38.  Test  Data  for  ALU.VHD  with  Sensors 

Output  #0  stuck  low  at  601 
Input  #0  stuck  low  at  601 
Input  #1  stuck  low  at  601 

Figure  39.  Faults  Found  in  ALU.VHD  With  Probes 

One  characteristic  of  combinatorial  digital  logic  is  that  most  faults  cannot  be  found  using  one 
set  of  test  data.  For  example,  if  an  input  was  stuck  low,  and  the  actual  signal  value  was  low,  the 
circuit  would  operate  correctly.  The  circuit’s  sensors  would  show  the  correct  result  for  this  set  of 
commands.  The  fault  will  only  become  apparent  when  the  signal  value  is  high. 

^.2  Improvements 

4.2.1  Improving  the  Hypothesis  Generator  Calvin  currently  takes  all  components  upstream 
from  the  incorrect  output  and  places  them  in  the  suspect  queue.  Calvin  could  use  knowledge  of 
boolean  algebra  to  better  select  candidate  suspects.  For  example,  consider  one  bit  of  the  ALU 
shown  in  Figure  ref401.  Assume  that  both  data  inputs  are  high,  and  the  select  line  is  high  for  an 
OR  operation.  When  simulating  the  circuit’s  processes,  Calvin  would  place  “reasons”  for  a  signal’s 
value  in  the  activation  record  along  with  the  signal’s  new  value.  These  could  then  be  placed  in  the 
Behave  object.  For  OR  gate  1605,  the  value  on  output  signal  1530  would  be  1  because  of  input 
signal  I004’s  1  state.  Now,  suppose  that  the  signal  1530  is  found  to  be  low  instead  of  the  simulated 
high  state.  Since  1530  was  caused  by  1003,  and  OR  gate  1605  was  assumed  to  be  working,  Calvin 
would  not  have  to  consider  components  upstream  from  the  other  input,  1003.  (11:394-396) 

4.2.2  Probing  By  bringing  out  internal  signals  to  sensors,  Calvin  reduced  the  number  of 
suspect  hypotheses  dramatically.  This  is,  in  effect,  inserting  additional  probes  into  the  circuit. 
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Calvin  contains  component  connection  data  within  its  Behave  and  Signal  objects.  Reasoning 
with  this  information,  an  additional  module  can  suggest  possible  signal  lines  to  monitor. 

An  easy  way  would  be  to  reason  from  the  topology  of  the  circuit.  A  simple  way  would  be  to 
ask  for  the  value  of  the  signal  immediately  upstream  from  the  incorrect  output.  If  this  matches  the 
simulated  signal’s  value,  the  component  downstream  must  be  the  culprit.  If  not,  continue  upstream. 
Calvin  can  support  this  technique,  with  its  driver _bi  field  in  the  Signal  object. 

A  more  efficient  technique,  described  by  Davis  and  Hamscher,  would  be  to  perform  what  is 
in  effect  a  binary  search.  Examining  the  connection  diagram  of  the  circuit,  Calvin  could  select  a 
signal  that  roughly  divides  the  circuit  into  two  section.  If  that  signal’s  actual  value  still  does  not 
match  the  Simulated  value,  all  components  downstream  from  that  signal  are  exonerated.  This  can 
continue,  ideally  splitting  the  suspect  components  into  two  groups  each  time,  until  a  single  suspect 
is  found.  (11:410-411) 

4-2. 3  Extending  the  VHDL  language  As  with  all  mode''^,  VHDL  has  some  limitations. 
VHDL  lacks  a  way  to  describe  easily  the  physical  layout  of  a  system.  Examining  the  VHDL 
source  for  the  ALU  in  Appendix  B.2,  one  cannot  determine  if  the  OR  gates  are  on  a  common  IC. 
This  prevents  easily  determining  faults  such  as  solder  bridges,  or  broken  power  pins.  Although  a 
single  fault,  the  effects  might  be  seen  in  two  entirely  separate  parts  of  the  circuit. 

One  way  of  extending  the  language  for  diagnostic  purposes  would  be  adding  commands  for 
explicitly  stating  what  certain  errors  might  do.  The  C  language  handles  implementation  specific 
features  by  the  pragma  keyword;  in  VHDL  this  might  be  handled  with  any  new  keywords  embedded 
within  comment  lines.  These  additions  could  link  any  processes  that  describe  error  conditions  to 
those  that  describe  proper  behavior.  In  Calvin,  this  would  require  additions  only  to  the  parser;  the 
errant  processes  would  be  linked  to  proper  behaviors. 
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4-2.4  Interfacing  with  an  Expert  System  Calvin,  as  it  exists  now,  only  has  the  rudiments  of 
AI  behavior.  A  rule-based  expert  system  could  be  interfaced  with  Calvin,  turning  it  into  a  hybrid 
model-based/rule-based  system.  Obvious  places  that  would  benefit  would  be  the  fault-hypothesis 
and  the  suspect  selection. 

Knowledge  that  certain  subcomponents  have  a  high  failure  rate  could  be  placed  in  the  source. 
A  good  place  would  be  in  library  packages  that  are  reused.  With  rules  based  on  this  information, 
the  suspect  queue  could  be  reordered  to  place  these  components  nearer  the  front  Although  this 
would  not  improve  the  current  implementation,  a  real-time  version  might  be  able  to  come  up  with 
a  “best  guess”  if  there  is  not  enough  time  to  complete  the  algorithm. 

4-3  Summary 

In  this  chapter  I  discussed  three  VHDL  descriptions  that  Calvin  used.  Then  I  discussed  ways 
in  which  the  current  Calvin  program  can  be  extended  and  made  more  powerful.  In  the  next  chapter 
I  will  summarize  the  thesis  and  discuss  my  recommendations  for  future  work. 
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V.  Observations  and  Recommendations 


5.1  Review 

In  Chapter  1  is  a  review  of  the  problem  that  this  thesis  attacks.  Chapter  2  records  a  review  of 
some  model-based  r’  agnostic  techniques,  including  Scarl’s  “Full  consistency”  and  Dries’  “Diagnose” 
algorithms.  Chapter  3  contains  a  description  of  Calvin,  including  the  internal  structures  and 
algorithms.  A  description  of  the  test  programs  is  in  Chapter  4,  along  with  ideas  on  how  Calvin  can 
be  extended. 

5.2  Accomplishments 

In  this  thesis  effort  I  designed  Calvin,  a  model-based  diagnostic  system  that  used  VHDL  to 
describe  the  model.  Calvin  is  a  starting  point  that  can  be  wsed  for  more  powerful  model-baised 
paradigms.  Some  of  my  accomplishments  during  this  effort: 

•  VHDL  can  be  used  to  describe  the  model  for  a  model-based  diagnostic  technique.  VHDL  was 
designed  to  be  a  description  language,  and  future  Air  Force  contracts  mandate  its  use. 

•  The  goal  of  creating  Calvin  was  to  develop  a  VHDL  system  that  can  be  used  for  implementing 
model-based  diagnostic  techniques.  I  did  this  by: 

—  Implementing  a  VHDL  parser  that  generated  a  representation  of  a  system  from  a  VHDL 
source  file.  This  representation  included  all  the  necessary  information  for  reasoning 
about  the  structure  of  the  components  in  the  system,  as  well  as  the  behavior  of  those 
comj^  .  .n,s. 

-  Implementing  a  VHDL  simulator  that  could  take  the  representation  from  the  parser  and 
a  set  of  input  values,  and  simulate  the  system  generating  output  values. 

-  Creating  routines  that  could  modify  the  parsed  representation  so  that  errors  in  the 
behavior  of  the  original  circuit  can  be  simulated. 
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•  I  implemented  a  version  of  Scarl’s  “full  consistency”  algorithm  that  was  based  on  Dries’ 
“Diagnose”  algorithm. 

5.3  Recommendations 

Based  on  my  experiences,  the  following  is  a  list  of  recommendations  for  future  work: 

•  Expand  the  implemented  VHDL  language.  The  implemented  subset  is  limited  to  only  logi¬ 
cal  operations.  Expanding  the  VHDL  constructs  that  Calvin  can  recognize  will  allow  much 
more  complex  systems.  These  include  those  whose  behavior  is  described  by  loops  or  condi¬ 
tional  statements.  Implementing  the  VHDL  TYPE  command  would  allow  multi-value  logic 
systems,  such  as  an  “OFF”  state.  Diagnosing  analog  systems  would  require  floating  point 
arithmetic.  Since  the  parser  ignores  unknown  constructs,  there  should  not  have  to  be  much 
rewriting  of  existing  code. 

•  Implement  the  probing  improvements  that  Chapter  4  describes.  These  should  be  the  easiest 
to  add.  I  have  already  manually  placed  probes  in  the  source  code,  so  Calvin  should  not  need 
new  data  structures. 

•  Improve  the  hypothesis  generator.  Here  should  be  the  easiest  place  to  put  “real  AI”  into 
Calvin.  Calvin  already  hcis  the  data  structures  for  recisoning  on  the  structure  of  the  circuit. 
The  hardest  problem  may  be  reasoning  from  the  VHDL  processes. 

•  Extend  the  diagnostic  algorithm.  The  current  algorithm  only  allows  non-time-dependent 
systems  to  be  diagnosed.  The  VIIDL  model  contains  time  information,  so  there  should  be 
a  way  to  reason  on  systems  that  have  “memory,"  such  as  .sequential  systems.  One  way  may 
be  to  maintain  the  lis  of  suspects,  and  use  that  information  w'hen  new  inputs  enter  the  test 
.system.  The  new  values  should  affirm  certain  hypotheses  and  reject  others. 


5-4  Summary 


To  perform  model-based  diagnostics,  there  must  be  some  model  to  reason  from.  To  keep 
from  having  to  build  a  new  diagnostic  system  for  each  new  product,  a  language  can  be  used  for  the 
model  of  the  product.  One  approach  may  be  to  create  a  special-purpose  language  for  describing 
the  model;  however,  there  are  already  description  languages  in  existence.  One  of  these  languages 
is  VHDL,  a  VHSIC  hardware  description  language.  Calvin  uses  VHDL  as  a  model  description 
language. 

In  artificial  intelligence  applications,  sometimes  it  seems  as  if  very  little  of  the  project  involves 
any  “artificial  intelligence.”  Instead,  most  of  the  effort  is  in  creating  a  platform  for  the  application. 
This  is  also  true  for  using  VHDL  for  model-based  diagnostics.  Most  of  my  time  was  spent  getting 
the  simulator  and  parser  portions  of  Calvin  working.  A  lot  of  the  rest  was  taken  up  interfacing 
Dries’  Diagnose  algorithm  with  the  simulator  and  parser. 

With  Calvin,  I  have  created  an  important  framework  that  future  researchers  can  easily  extend. 
Future  work  should  be  on  extending  Calvin’s  diagnostic  and  simulation  routines. 
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Appendix  A.  Supported  VHDL  Grammar 


entity -declaration  ;;= 

ENTITY  identifier  IS 
entity  Jieader 
entity-declarative-part 
END; 


entity -header  ::= 
port-clause 


port-clause  :;= 

port  (  formal-port  Jist  ); 


formal-port-list 

[format4)ort-element] 

formal4)ort-element 

SIGNAL  identifierJist  :  mode 

I  SIGNAL  identifierJist  :  mode  ;  formal-port-element 


mode  :;= 

IN 

1  OUT 

architecture-body  ::= 

ARCHITECTURE  identifier  OF  name  IS 
architecturc-declarative-part 
BEGIN 

architecture-statement-part 

END; 

architecture-declarative_part  ::= 

[block-declarative  Jtem] 

block-declarative Jtem 
signal -declaration 
I  component-declaration 

architecture-statement-part  :;= 
[concurrent-statement] 

configuration-declaration  ::= 

CONFIGURATION  identifier  OF  name  IS 
block-configuration 
END; 
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block.configuration  ::= 

FOR  biockjspecification 
use.clause 
configurationJtem 
END  FOR; 

block^pecification  ::= 
identifier 

use.clause  ::= 

USE  identifier[, identifier]; 

configurationJtem  ::= 

component-configuration 

component. configuration 

FOR  instantiationJist  :  identifier 
use-binding  Jndication 
block-configuration 
END  FOR; 

use.binding Jndication  :;= 

USE  binding  Jndication; 

binding  Jndication  ;;= 
entity  .aspect 

entity-aspect  ::= 

ENTITY  identifier  (  identifier  ) 

signaLdeclaration 

SIGNAL  identifierJist  :  BIT 

component.declaration  ::= 

COMPONENT  identifier 
port-local-portJist 
END  COMPONENT; 

portJocal.port.list  :;= 

(  local-portJist  ); 

local.portJist 

identifierJist  ;  local.port.mode  BIT 
1  identifierJist  :  local.portjnode  BIT; 
local-portJist 

local.portjnode  ::= 

IN 

I  OUT 
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concurrent^tatement  ::= 
processjstatement 

process-statement  ::= 

PROCESS 

BEGIN 

sequen  ce.of jstatements 
END  PROCESS; 

sequence-of-statements  ::= 
{sequential  jstatement} 

sequential  statement  : : = 

signal-assignmentjstatement 

signal-assignment-statement  ;:= 
target  ;=  waveform; 

terget  ::= 

identifier 

waveform  :;= 

expression  AFTER  expression 

expression  :;= 

relation^nd-relation 
I  relation_or.relation 
I  relation-nand_nor_relation 
I  relation.xor_relation 

relation-and-relation  ::= 
relation  AND  relation 

relation jor .relation  :;= 
relation  OR  relation 

relation_nand_nor_relation  ;:= 
relation 

I  relation  NAND  relation 
I  relation  NOR  relation 

relation-xor .relation 

relation  XOR  relation 


relation  ::= 

simplejexpression 


simple_expression  ;:= 
primary 

primary  ::= 
literal 
I  identifier 

literal 

numericJiteral 

numeric Jiteral 
decimalJnt 

decimal Jnt  ::= 

[digit] 
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Appendix  B.  VHDL  Source  Code 


B.l  Full- Adder 

This  section  contains  the  VHDL  source  for  a  full-adder.  This  file  was  used  by  Calvin. 

—  One-bit  lull-adder 

—  Consists  of  2  half-adders  and  an  OR  gate 

—  X  +  Y  +  Cin  =  Z  +  Cout 

—  This  full-adder  is  used  in  the  four-bit  adder 


-  OR  Gate 

entity  i015  is 
port( 


iOll: 

in 

Bit 

i012; 

in 

bit 

i013: 

out 

bit 

); 

end; 

architecture  i025  of  i015  is 
begin 

process 

begin 

i013  <=  iOll  or  i012  alter  5; 
end  process; 
end  iOlO; 


-  Half  adder 

entity  iOlO  is 
port( 


iOll: 

in 

Bit 

i012: 

in 

bit 

i013: 

out 

bit 

i014: 

out 

bit 

); 

end; 

2u:chitecture  i020  of  iOlO  is 
begin 

process 

begin 

1013  <=  iOll  xor  i012  after  5; 

1014  <=  iOll  and  i012  after  5; 
end  process; 
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end  iOlO; 


-  Full  Adder  - 

entity  iOSO  is 
port( 

i051,i0S2,i053:in  bit; 
iOS4 , iO&S : out  bit 

); 

end; 

architecture  i060  ot  iOSO  is 

signal  i090:bit; 
signal  i091:bit; 
signal  i092:bit; 
component  iOlO 
port( 

iOll:  in  Bit; 
i012:  in  bit; 
i013:  out  bit; 
i014:  out  bit 

); 

end  component; 
component  i030 
port( 

i011,i012:in  bit; 
i013:out  bit 

): 

end  component; 

begin 

i080:i010 
port  map( 

1011  =>  i051. 

1012  =>  i052, 

1013  =>  i090, 

1014  =>  i091  ); 

i081:i010 
port  map( 

1011  =>  i090. 

1012  =>  i063, 

1013  =>  iOS4, 

1014  =>  i092  ); 
i082:i030 

port  map( 

1011  =>  i091. 

1012  =>  i092, 

1013  =>  i065  ); 

end; 
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-  Circuit  - 

configuration  i099  of  iOSO  is 
for  i060 

for  i080,i081 :i010  use  entity  i010(i020); 
end  for; 

for  i082:i030  use  entity  i015(i025); ' 
end  for; 
end  for; 
end; 


B.2  Two  Operation  ALU 

This  section  contains  the  VHDL  source  for  a  two-operation  AND/OR  ALU  The  code  to 
simulate  probes  placed  in  the  circuit  are  commented  out  in  this  code. 


—  Three-bit,  Two-operation  ALU 

—  Performs  AND  or  OR  function  of  2  three-bit  veilues 

—  If  S=l,  A2A1A0  AND  B2B1B0  =  Z2Z1Z0 

—  If  S=0,  A2A1A0  OR  .B2B1B0  =  Z2Z1Z0 


—  This  example  has  the  probes  inserted  at  the  outputs 

—  of  the  AND/OR  functions  commented  out. 


-  OR  Gate  - 

entity  i200  is 
port( 

i201:  in  Bit; 
i202:  in  bit; 
i203:  out  bit 

): 

end; 

architecture  i299  of  i200  is 
begin 

process 

begin 

i203  <=  i201  or  i202  after  5; 
end  process; 
end; 


-  and  Gate  - 

entity  ilOO  is 
port( 

ilOl:  in  Bit; 
il02:  in  bit; 
il03:  '^ut  bit 

): 

end; 

architecture  il99  of  ilOO  is 
begin 

process 

begin 

il03  <=  ilOl  and  il02  after  5; 
end  process; 
end; 


-  INVGate 

entity  i300  is 
port( 

i301:  in  Bit; 
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end; 

architecture  1399  of  1300  is 
begin 

process 

begin 

1302  <=  not  1301  after  5; 
end  process; 
end; 


entity  iSOO  is 
port( 


1510 

:  in 

bit; 

—  A 

1511 

:  in 

bit; 

—  A 

1512 

:  in 

bit; 

—  A 

1520 

:  in 

bit; 

—  B 

1521 

:  in 

bit; 

"  B 

1522 

:  in 

bit; 

—  B 

1595 

:  in 

bit; 

—  sO 

1530 

:  out 

bit; 

—  Z 

1531 

:  out 

bit; 

—  Z 

1532 

:  out 

bit 

—  Z 

—  The  following  are  the  cosaaented-out  probes 


— 

1710 

:  out  bit; 

—  YOASD 

— 

1711 

:  out  bit ; 

—  YIAID 

— 

1712 

:  out  bit; 

--  YIAKD 

— 

1810 

:  out  bit ; 

—  YOOR 

— 

1811 

:  out  bit; 

--  YIOR 

— 

1812 

:  out  bit 

—  YIOR 

): 

end; 


architecture  1599  of  iSOO  is 

component  1100 
port(  ilOl, 

1102  In  Bit; 

1103  out  Bit  ) ; 

end  component; 

component  1200 
port(  1201, 

1202  In  Bit; 

1203  out  Bit  ) ; 

end  component; 


component  1300 


port(  i301  In  Bit; 

1302  Out  Bit  ) : 

end  component: 

signal 

iOOO, 

i001.i003,i004. 
i011,i013,i014, 
i021.i023,i024 
:  bit; 


—  The  comment ed-out  probes  have  been  replaced  by 

—  these  internal  signals 

signal  1710,1711,1712  :  bit; 
signal  1810,1811,1812  :  bit; 

begin 


—  Control 

line 

inverter 

1606: 

1300 

port 

map( 

i301=>i595. 

i302=>i000  ) 

» 

—  Bit 

;  0 

1601: 

1100 

port 

map( 

il01=>i510. 

il02=>i520. 

il03=>i710 

1602: 

1200 

port 

map( 

i201=>i510. 

i202=>i520. 

i203=>i810 

1603: 

1100 

port 

map( 

il01=>i710. 

il02=>i000. 

il03=>i003 

1604: 

1100 

port 

map( 

il01=>i810. 

il02=>i595. 

il03=>i004 

1605: 

1200 

port 

map( 

i201=>i003. 

i202=>i004. 

i203=>i530 

—  Bit 

;  1 

1611: 

1100 

port 

map( 

il01=>i511. 

il02=>i521. 

il03=>i711 

1612: 

1200 

port 

map( 

i201=>i511. 

i202=>i521. 

i203=>i811 

1613: 

1100 

port 

map( 

il01=>i711. 

il02=>i000. 

il03=>i013 

1614: 

1100 

port 

map( 

il01=>i811. 

il02=>i595. 

il03=>i014 

1615: 

1200 

port 

map( 

i201=>i013. 

i202=>i014. 

i203=>i531 

—  Bit 

2 

1621: 

1100 

port 

map( 

il01=>i512. 

il02=>i522. 

il03=>i712 

1622: 

1200 

port 

map( 

i201=>i512. 

i202=>i522. 

i203=>i812 

1623; 

1100 

port 

map( 

il01=>i712. 

il02=>i000. 

il03=>i023 

1624: 

1100 

port 

map( 

il01=>i812. 

il02=>i595. 

il03=>i024 

1625: 

1200 

port 

map( 

i201=>i023. 

i202=>i024. 

i203=>i532 

end; 


) 

) 

) 

) 

) 


) 

) 

) 

) 

) 


) 

) 

) 

) 

) 


-  Circuit  - 

configuration  iOOO  of  iSOO  is 
for  1599 

—  AND  gates 

for  1601 ,1603,1604: i 100  use  entity  il00(il99); 
end  for; 
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ioT  1611,1613.1614:1100  use  entity  1100(1199) 
end  for; 

for  1621,1623,1624:1100  use  entity  1100(1199) 
end  for; 

—  OR  gates 

for  1602,1605:1200  use  entity  1200(1299); 
end  for; 

for  1612,1615:1200  use  entity  1200(1299); 
end  for; 

for  1622,1625:1200  use  entity  1200(1299); 
end  for; 

—  IHV  gates 

for  1606:1300  use  entity  1300(1399); 
end  for; 

end  for; 
end; 
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B.3  Two  Operation  ALU  with  Probes 

This  section  contains  the  VHDL  source  for  a  two-operation  AND/OR  ALU  This  code  contains 
the  probes  placed  in  the  circuit. 


—  Three-bit,  Two-operation  ALU 

—  Performs  AND  or  OR  function  of  2  three-bit  values 

—  If  S=l,  A2A1A0  AND  B2B1B0  =  Z221Z0 

—  If  5=0.  A2A1A0  OR  B2B1B0  =  Z2Z1Z0 


—  This  example  has  the  probes  inserted  at  the  outputs 

—  of  the  AND/OR  functions.  The-  3  bring  the  results  of  both 

—  functions  to  sensors. 


-  OR  Gate  - 

entity  i200  is 
port( 

i201;  in  Bit; 
i202;  in  bit; 
i203:  out  bit 

); 

end; 

architecture  i299  of  i200  is 
begin 

process 

begin 

i203  <=  i201  or  i202  after  5; 
end  process; 
end; 


-  AND  Gate  - 

entity  ilOO  is 
port( 

ilOl:  in  Bit; 
il02:  in  bit; 
il03:  out  bit 

): 

end; 

architecture  il99  of  ilOO  is 
begin 

process 

begin 

il03  <=  ilOl  and  il02  after  5; 
end  process ; 
end; 


-  IHVGate 

entity  i300  is 
port( 


84 


1301:  in  Bit; 

1302:  out  bit 

): 

end; 

architecture  1399  of  1300  is 
begin 

process 

begin 

1302  <=  not  1301  after  5; 
end  process; 
end; 


entity  iSOO  is 
port( 


1510 

:  in 

bit;  — 

A 

1511 

:  in 

bit;  — 

A 

1512 

:  in 

bit;  — 

A 

1520 

:  in 

bit;  — 

B 

1521 

:  in 

bit ;  — 

B 

1522 

:  in 

bit;  — 

B 

1595 

:  in 

bit;  — 

sO 

1530 

:  out 

bit ;  — 

Z 

1531 

:  out 

bit;  — 

Z 

1532 

:  out 

bit;  — 

Z 

—  These  output  signals  are  the  probes 


1710 

:  out  bit; 

—  YOABD 

1711 

:  out  bit ; 

—  YIAID 

1712 

:  out  bit ; 

--  YIAMD 

1810 

:  out  bit ; 

—  YOOR 

1811 

:  out  bit ; 

--  YIOR 

1812 

:  out  bit 

--  YIOR 

); 


end; 


architecture  1599  of  1500  is 


component  1100 
port(  1101, 

1102  In  Bit; 

1103  out  Bit  ) ; 

end  component; 

component  1200 
port(  1201, 

1202  In  Bit; 

1203  out  Bit  ) ; 

end  component ; 
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component  1300 

port(  1301  :  In  Bit; 

1302  Out  Bit  } ; 

end  component; 

signal 

1000, 

1001,1003,1004. 

1011,1013,1014, 

1021,1023,1024 
:  bit; 

begin 

—  Control  line  Inverter 

1606:  1300  port  map(  1301=>1595,  1302=>1000  ); 

—  Bit  0 

1601:  1100  port  map(  1101=>1510,  1102=>1520,  1103=>1710  ) 

1602:  1200  port  map(  1201=>1S10,  1202=>1520,  1203=>1810  ) 

1603:  1100  port  map(  1101=>i710,  1102=>1000,  1103=>1003  ) 

1604:  1100  port  map(  1101=>i810,  1102=>159S,  1103=>1004  ) 

160S:  1200  port  map(  1201=>i003,  1202=>1004,  1203=>1530  ) 

—  Bit  1 

1611;  1100  port  map(  il01=>i511,  il02=>i521,  il03=>i711  ) 

1612;  1200  port  map(  i201=>i511,  i202=>i521,  i203=>1811  ) 

1613:  1100  port  map(  il01=>i711,  il02=>i000,  il03=>i013  ) 

1614;  1100  port  map(  il01=>i811,  il02=>i596,  il03=>i014  ) 

1615;  1200  port  map(  i201=>i013,  i202=>i014,  i203=>i531  ) 

—  Bit  2 

1621:  1100  port  map(  il01=>i512,  il02=>i522,  il03=>i712  ) 

1622:  1200  port  map(  i201=>i512,  i202=>iS22,  i203=>i812  ) 

1623:  1100  port  map(  1101=>i712,  1102=>1000,  il03=>i023  ) 

1624:  1100  port  map(  il01=>i812.  il02=>i696,  il03=>i024  ) 

1625:  1200  port  map(  1201 =>1023,  i202=>i024,  i203=>i532  ) 

end; 


-  Circuit  - 

configuration  1000  of  1500  Is 
for  1599 

—  AND  gates 

for  1601 ,1603 ,1604: 1100  use  entity  1100(1199); 
end  for; 

for  1611,1613,1614: 1100  use  entity  1100(1199); 
end  for; 

for  1621 ,1623,1624: 1100  use  entity  1100(1199); 
end  for; 


—  OR  gates 

for  1602,1605:1200  use  entity  1200(1299); 
end  for; 

for  1612,1615:1200  use  entity  1200(1299); 
end  for; 

for  1622,1625:1200  use  entity  1200(1299); 
end  for; 

—  IHV  gates 

for  1606:1300  use  entity  1300(1399); 
end  for; 

end  for; 
end; 


B.4  Four-bit  Adder 

This  section  contains  the  VHDL  source  for  a  four-bit  adder.  This  code  was  used  by  Calvin. 


—  Four-bit  Adder 

—  Consists  of  4  lull-adders  in  cascade 

—  X3X2X1X0  +  Y3Y2Y1Y0  +  Cin  =  Z3Z2Z1Z0  +  Cout 


-  OR  Gate 

entity  iOlS  is 
port( 


iOll: 

in 

Bit 

i012: 

in 

bit 

i013: 

out 

bit 

); 

end; 

eurchitecture  i025  ol  iOlS  is 
begin 

process 

begin 

i013  <=  iOll  or  i012  alter  5; 
end  process; 
end  iOlO; 


-  Hall  adder 

entity  iOlO  is 
port( 


iOll: 

in 

Bit 

i012: 

in 

bit 

i013: 

out 

bit 

i014: 

out 

bit 

); 

end; 

architecture  i020  ol  iOlO  is 
begin 

process 

begin 

1013  <=  iOll  xor  i012  alter  6; 

1014  <=  iOll  and  i012  alter  5; 
end  process; 

end  i020; 


-  Full  Adder  - 

entity  i050  is 
port( 

ilOO  :  in  bit;  —  Cin 
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1110, 

— 

XO 

1111, 

— 

XI 

1112, 

— 

X2 

1113 

in 

bit; 

— 

X3 

1120, 

— 

YO 

1121, 

— 

Y1 

1122, 

— 

Y2 

1123 

In 

bit; 

— 

Y3 

1130, 

— 

ZO 

1131, 

— 

Z1 

1132, 

— 

Z2 

1133 

out 

bit; 

— 

Z3 

1140, 

— 

coutO 

1141, 

— 

coutl 

1142 

out 

bit; 

— 

cout2 

1143 

out 

bit 

— 

Gout 

): 

end; 

architecture  1060  of  iOSO  is 


signal  1200.1201 ,1202: bit; 
signal  1210, 1211, 1212: bit; 
signal  1220, 122 1,1222: bit; 
signal  1230, 123 1,1232  .-bit; 

component  1010 
port( 

1011:  In  Bit; 

1012:  in  bit; 

1013:  out  bit; 

1014:  out  bit 

): 

end  component; 
component  1030 
port( 

101 1,1012: In  bit; 
1013: out  bit 

): 

end  component; 

begin 
—  Bit  0 
iSOOriOlO 
port  map( 

1011  =>  1110, 

1012  =>  1120, 

1013  =>  1200, 

1014  =>  1201  ); 
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1501:1010 
port  map( 
1011  => 
1012  => 

1013  => 

1014  => 

1502:1030 
port  map( 
1011  => 
1012  => 
1013  => 


Bit  1 
1610:1010 
port  BtapC 
1011  => 
1012  => 

1013  => 

1014  => 

1611:1010 
port  map( 
1011  => 
1012  => 

1013  => 

1014  => 

1512:1030 
port  map( 
1011  => 
1012  => 
1013  => 

Bit  2 
1520:1010 
port  map( 
1011  => 
1012  => 

1013  => 

1014  => 

1521:1010 
port  aap( 
1011  => 
1012  => 

1013  => 

1014  => 

1622:1030 
port  inap( 
1011  => 


1200, 
1100, 
1130, 
1202  ); 


1202, 
1201, 
1140  ); 


1111, 
1121, 
1210, 
1211  ); 


1210, 
1140, 
1131, 
1212  ); 


1212, 
1211, 
1141  ): 


1112, 
1122, 
1220, 
1221  ); 


1220, 
1141, 
1132, 
1222  ); 


1222, 
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1012  =>  i221, 

1013  =>  il42  ); 

“  Bit  3 
i530:i010 
port  map( 

1011  =>  1113, 

1012  =>  il23, 

1013  =>  i230, 

1014  =>  1231  ); 

i531:i010 
port  map( 

1011  =>  i230, 

1012  =>  il42, 

1013  =>  il33, 

1014  =>  1232  ) ; 

1532:1030 
port  nap( 

1011  =>  1232, 

1012  =>  1231, 

1013  =>  1143  ); 

end; 


-  Circuit  - 

configuration  1099  of  1050  Is 
for  1060 

for  1500,1501:1010  use  entity  1010(1020); 
end  for; 

for  1502:1030  use  entity  1015(1025); 
end  for; 

for  1510,1511:1010  use  entity  1010(1020); 
end  for; 

for  1512:1030  use  entity  1015(1025); 
end  for; 

for  1520,1521:1010  use  entity  1010(1020); 
end  for; 

for  1522:1030  use  entity  1015(1025); 
end  for; 

for  1530,1531:1010  use  entity  1010(1020); 
end  for; 

for  1532:1030  use  entity  1015(1025); 
end  for; 
end  for; 
end; 
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B.5  Five- bit  2’s  Compliment  ALU 

This  section  contains  the  VHDL  source  for  a  five-bit  2’s  Compliment  ALU.  The  ALU  performs 
addition  and  subtraction.  This  section  is  included  as  an  additional  example  that  can  be  used  with 
Calvin. 

—  This  code  describes  a  5  bit  2's  bit  ALU. 

—  Operations  include  add  and  subtract  of  tuo 

—  5-bit  2’s  compliment  numbers. 


-  GR  Gate 

entity  ilOO  is 
port( 


ilOl: 

in 

Bit 

il02: 

in 

bit 

il03: 

out 

bit 

): 

end; 

architecture  il99  of  ilOO  is 
begin 

process 

begin 

il03  <=  ilOl  or  il02  after  5; 
end  process; 
end; 


-  AID  Gate  - 

entity  i200  is 
port( 

i201:  in  Bit; 
i202:  in  bit; 
i203:  out  bit 

): 

end; 

architecture  i299  of  i200  is 
begin 

process 

begin 

i203  <=  i201  eoid  i202  after  5; 
end  process; 
end; 


-  IHVGate  - 

entity  i300  is 
port( 

i301:  in  Bit; 
i302:  out  bit 

); 

end; 

architecture  i399  of  i300  is 
begin 
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process 

begin 

i302  <=  not  i301  alter  5; 
end  process; 
end; 


—  FULL_ADDER 
entity  i400  is 
port( 

i401 :  in  bit ;  —  x 

i402:  in  bit;  —  y 

i403:  in  bit;  —  Cin 

i404:  out  bit;  —  Sum 

i405:  out  bit  —  Cout 

): 

end; 

eurchitecture  i499  of  i400  is 
begin 

process 

begin 

1404  <=  i401  xor  i402  xor  i403  alter  6; 

1405  <=  (i401  and  i402)  or 

(i403  and  i401)  or 

(i403  and  i402)  alter  5; 

end  process; 
end; 


entity  iSOO  is 
port( 


iSlO 

in 

bit 

“  X 

iSll 

in 

bit 

i512 

in 

bit 

i513 

in 

bit 

i514 

in 

bit 

i520 

in 

bit 

—  Y 

i521 

in 

bit 

i522 

in 

bit 

i523 

in 

bit 

i524 

in 

bit 

i544 

in 

bit 

—  add 

i645 

in 

bit 

—  sub 

iS30 

out 

bit 

—  S 

i531 

out 

bit 

iS32 

out 

bit 

i633 

out 

bit 

iS34 

out 

bit 

): 

end; 

curchitecture  i599  ol  iSOO  is 
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component  1200 
port(  1201. 

1202  In  Bit; 

1203  out  Bit  ) ; 

end  component; 

component  1100 
port(  1101, 

1102  In  Bit; 

1103  out  Bit  ) ; 

end  component; 

component  1300 

port(  1301  In  Bit; 

1302  Out  Bit  ) ; 

end  component; 

component  1400 
port  ( 

1401:  In  bit;  —  x 

1402:  In  bit;  —  y 

1403:  In  bit;  —  Cln 

1404:  out  bit;  —  Sum 

140S:  out  bit  —  Cout 

); 

end  component; 
signal  1998, 

1001,  1002,  1003,  1004,  1005,  1900, 

1011,  1012,  1013,  1014,  1015,  1901, 

1021,  1022,  1023,  1024,  1025,  1902, 

1031,  1032,  1033,  1034,  1035,  1903, 

1041,  1042,  1043,  1044,  1045,  1904  :  Bit; 

begin 

1701  :  1100  port  map(  1101=>1544,  1102=>1545,  1103=>1998  ); 

—  Bit  add/ sub 

—  Bit  0 

1710  :  1300  port  map(  1301=>1520,  1302=>1001  ); 

1711  :  1200  port  map(  1201=>1545,  1202=>1001,  1203=>1002  ); 

1712  :  1200  port  map(  1201=>1544,  1202=>1620,  1203=>1003  ); 

1713  :  1200  port  map(  1201=>1510,  1202=>1998,  1203=>1004  ); 

1714  :  1100  port  map(  1101=>1003,  1102=>1002,  1103=>1005  ); 

1715  :  1400  port  map(  1401=>1004,  1402=>1005,  1403=>1545, 

1404=>1530,  1405=>1900  ); 

—  Bit  1 

1720  :  1300  port  map(  1301=>1521,  1302=>1011  ); 

1721  :  1200  port  map(  1201=>1545,  1202=>1011,  1203=>1012  ); 

1722  :  1200  port  map(  1201=>1544.  1202=>1621.  1203=>1013  ); 

1723  :  1200  port  map(  1201=>1B11,  1202=>1998,  1203=>1014  ); 
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1724  :  1100  port  aapC  1101=>1013, 

1725  :  1400  port  aapC  1401=>1014. 

1404=>1531.  1406=>1901  ); 

--  Bit  2 

1730  :  1300  port  aapC  1301=>1522. 

1731  :  1200  port  aapC  1201=>1021, 

1732  :  1200  port  aapC  1201=>1544. 

1733  :  1200  port  aapC  1201=>1512, 

1734  :  1100  port  aapC  1101=>1023, 

1735  :  1400  port  Bap(  1401=>1024, 

1404=>1532.  1405=>1902  ); 

--  Bit  3 

1740  :  1300  port  aapC  1301=>1523, 

1741  :  1200  port  aapC  1201=>1031, 

1742  :  1200  port  aapC  1201=>1544. 

1743  :  1200  port  map(  1201=>1513, 

1744  :  1100  port  map(  1101=>1033, 

1745  ;  1400  port  aapC  1401=>1034, 

1404=>1533,  1405=>1903  ); 

—  Bit  4 

1750  :  1300  port  aapC  1301=>1524. 

1751  :  1200  port  aapC  1201=>1041, 

1752  :  1200  port  aapC  1201=>1544, 

1753  :  1200  port  Bap(  1201s>1514, 

1754  :  1100  port  Bap(  1101=>1043. 

1755  :  1400  port  Bap(  1401s>1044, 

1404=>1534,  1405=>1904  ); 

— Done 
end; 


1102=>1012.  1103=>1015  ); 
1402=>1015.  1403=>1900, 


1302=>1021  ); 

1202=>1545.  1203=>1022  ) 
1202=>1522.  1203=>1023  ) 
1202=>1998.  1203=>1024  ) 
1102=>1022,  1103=>1025  ) 
1402=>1025,  1403=>1901, 


1302=>1031  ); 

1202=>1545.  1203=>1032  ) 
1202=>1523,  1203=>1033  ) 
1202=>1998.  1203=>1034  ) 
1102=>1032.  1103=>1035  ) 
1402=>1035,  1403=>1902, 


1302=>1041 

1202=>1545, 

1202=>1524, 

1202=>1998, 

1102=>1042. 

1402=>1045, 


1203=>1042  ) 
1203=>1043  ) 
1203=:>1044  ) 
1103*>1045  ) 
1403=>1903, 


-  Circuit  - 

configuration  1000  of  1500  Is 
for  1599 

for  1701:1100  use  entity  1100(1199); 
end  for; 

for  1710,1720,1730,1740,1750:1300  use  entity  1300(1399); 
end  for; 

for  1711,1712,1713,1721, 

1722,1723,1731,1732, 

1733,1741,1742,1743, 

1751,1752,1753:1200  use  entity  1200(1299); 
end  for; 

for  1714,1724,1734,1744,1754:1100  use  entity  1100(1199); 
end  for; 

for  1715,1725,1735,1745,1755:1400  use  entity  1400(1499); 
end  for; 
end  for; 
end; 
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Appendix  C.  FLEX  modifications 


Before  the  Borland  C++  3.1  compiler  could  compile  the  output  of  FLEX,  some  changes  had 
to  be  made  to  FLEX.SKL  file.  This  file  forms  the  skeleton  of  the  FLEX  output  file.  The  following 
changes  were  made: 

1.  Remove  line  23  -  “#include  <osfcn.h>” 

2.  Remove  line  33  -  “#ifdef  _STDC_” 

3.  Remove  line  46  -  “#endif  —STDC..” 

No  changes  were  required  for  Bison. 
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Appendix  D.  Compiler-compiler  Source  Code 


D.l  Overview 

This  module  contains  code  for  the  compiler-compilers  Bison  and  FLEX.  The  module  UV 
describes  the  grammar  for  VHDL.  The  individual  VHDL  tokens  are  parsed  by  FLEX  according  to 
the  module  UV.LEX.  These  tokens  are  then  parsed  according  to  the  VHDL  grammar.  As  soon  as 
a  construct  has  been  recognized,  the  appropriate  parser  module  is  called  to  fill  in  the  data.  These 
modules  are  described  in  Appendix  E. 


D.2  UV 
/* 


FILE:  UV 

This  is  the  parser  lile  lor  Calvin. 

The  simulator  objects  are  built  up  by  calling  external  C/C+tlunctions 
defined  in  the  Parser  modules. 


*/ 

** 

**  Portions  of  the  following  code  was  extracted  from 
**  LALR(l)  grammar  for  AMSI  Ada  (public  domain) 

**  by  Herman  Fischer 

**  adapted  by:  Gerry  Fisher  t  Philippe  Charles 
♦♦ 

VHDL  source  lor  yacc 
**  syntax  analysis  with  error  recovery 
**  symbol  table 
**  memory  allocation 
vv  no  code  generation 
**  shift/reduce  conflicts:  1 

** 

**  Symbol  conventions  used: 


[foo] 

is  denoted  _foo_ 

floo} 

is  denoted  _ loo _ 

<,  foo  } 

is  denoted  _ loo _ 

foo_bar 

is  a  single  nonterminal 
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FOO _ bar  is  a  nontenBin2Ll  vhere  the  keyword  FOO  is 

ee  followed  by  a  nonterminal  bair 

** 

//  History  of  original  VHDL  grammar 

/m*************************************************************************** 

* 

*  Date:  19  I’eb,  1990  S.  Datta,  Univ  of  Cincinnati 

* 

*This  file  currently  contains  3  shift/reduce  and  3  reduce/reduce  conflicts: 

e 

*Shif t/reduce  conflicts : 

* 

*  1.  name  ->  simple.name 

*2uid  .architecture.identifier.  ->  LeftParen  simple.name  RightParen.ERR 
*cause  1  shift/reduce  conflict. 

♦ 

*  2.  attribute.name  ->  name  Apostrophe  attribute.designator  .aggregate. 

^causes  1  shift/reduce  conflict  (since  .aggregate.  ->  I  aggregate) 

* 

*  3.  component_instantiation_statement  ->  a.label  name 
♦.generic_map_aspect.  .port_map_aspect .  Semicolon_ERR 
^causes  1  shift/reduce  conflict  (with  .generic_map_aspect. ) . 

* 

*Reduce/reduce  conflicts : 

♦ 

*  1 .  range  ->  attribute.name 

♦and  name  ->  attribute.name  causes  1  reduce/reduce  conflict. 

* 

*  2.  expanded.name  ->  simple.name 

♦and  name  ->  simple.name  causes  2  reduce/reduce  conflicts. 

* 

♦To  avoid  conflicts  while  implementing  on  an  LALR(l)  shift-reduce 
♦parser-generator  such  as  YACC  or  BISOH,  the  originsd  IEEE-1076  VHDL  grammar 
♦has  been  modified  at  appropriate  places: 

* 

♦The  production  for  formal.port.element  contains  "type_mark  .constraint." 
♦instead  of  ".name,  type .mark  .constraint."  (ie  instead  of  subtype.indication) 
♦(AFIT  file  contains  only  "type.mark") 

* 

♦The  production  for  formal.generic.element  contains  "type.mark  .constraint." 
♦instead  of  ".name,  type.mark  .constraint."  (ie  instead  of  subtype.indication) 
♦(AFIT  file  contains  only  "type.mark") 

* 

♦In  the  production  for  architecture.body,  "simple.name"  (AFIT)  has  been 
♦changed  to  "name"  in  accordance  with  the  LRM 
* 

♦The  production  for  conf iguration.declaration  contains  "name"  instead  of 
♦"entity.name"  (LRM),  or  "Identifier"  (AFIT) 

♦ 

♦Missing  Semicolon.ERR  at  end  of  production  for  block.conf iguration  (in  AFIT 
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'•'file)  has  been  set  right. 

>•' 

'•‘In  production  for  block_specif ication,  "ncune"  causes  conflict  amd  has  not 
'^been  implenented. 

* 

*In  production  for  component.conf iguration,  "Identifier"  (AFIT)  has  been 
^replaced  by  "name"  in  accordance  with  the  LRM  definition.  Besides,  missing 
^■Semicolon.ERR  (in  AFIT  file)  has  been  set  right. 

* 

'•'In  production  for  operator.symbol,  "sign"  has  not  been  implemented.  Besides, 
'^"StringLit"  (absent  in  AFIT  file)  has  been  added  in  accordance  vith  the  LRM 
'•'definition.  Also,  "logical.operator"  and  "miscelaneous.operator" ,  and 
'^productions  for  them  have  been  added  (these  mere  commented  out  in  the  AFIT 
'^f  ile) . 

<•> 

'^In  production  for  procedure_parameter_element,  ".name.  type_mark 
♦.constraint."  (or  subtype_indication)  has  been  replaced  with  "type.mark 
'•'.constraint.".  AFIT  file  contains  only  "type_mark". 

♦In  production  for  function_parameter_element ,  ".name.  type_mark 
♦.constraint."  (or  subtype_indication)  has  been  replaced  with  "type_mark 
♦.constraint.".  AFIT  file  contains  only  "type_mark". 

* 

♦In  production  for  scalar_type_def inition,  "range_type_def inition"  includes 
♦both  integer  and  floating  point  types. 

♦ 

♦In  production  for  index_subtype_def inition,  "type_mark"  (LRM)  has  been 
♦replaced  by  "n^une". 

* 

♦In  production  for  discrete.range ,  "subtype_indication"  (ie  ".name. 

♦type.mark  .constraint."  in  LRM)  has  been  replaced  by  "name  range.constraint 
♦I  type_mark".  lote:  "constraint"  (LRM)  implies  "range_constraint"  or 

♦  "index_constraint" ,  but  "index.constraint"  has  been  ommitted  in  the 
♦production  for  discrete.range.  This  is  the  same  as  the  AFIT  file,  except  that 
♦"type_mark"  has  also  been  ommitted  in  AFIT  file,  since  it  causes  2 
♦reduce/reduce  errors. 

* 

♦Missing  Semicolon.ERR  in  AFIT  file  for  the  production  for 
♦incomplete.type.declaration  has  been  set  right  here. 

♦ 

♦This  file  as  well  as  AFIT  file  contains  "exp2uided_name"  in  production  for 
♦"type_mark"  to  avoid  conflict  between  "type_mark"  and  "constraint". 

* 

♦In  production  for  constraint,  "index.constraint"  has  been  replaced  by 
♦"aggregate",  both  in  this  as  well  as  the  AFIT  file. 

* 

♦Missing  Semicolon.ERR  in  AFIT  file  for  the  production  for  f ile.declaration 
♦has  been  set  right. 

* 

♦In  production  for  association.element,  ".formal_part_Arrow.  actual.part" 

♦has  been  replaced  by  "name  Arrow  OPEH.or. expression  I  OPEI.or.expression" . 
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* 

♦Productions  lor  "formal.part"  and  "actual_part"  have  been  replaced  by  their 
♦equiveilents .  (ie  formzd._part  ->  name  I  LeftParen  name  RightParen; 

♦actual_part  ->  OPEI_or_expression  I  LeltParen  OPEH_or_expression  RightParen;) 

♦ 

♦In  production  lor  local_port_element ,  "subtype_indication  .BUS. 
♦.VarAsgn_expression."  has  been  replaced  by  "type.mark  .constraint."  in  this 
♦lile,  and  "type_m2urk"  in  the  AFIT  lile. 

* 

♦In  production  lor  local_generic_element ,  “subtype.indication 
♦.VarAsgn.expression."  has  been  replaced  by  "type.mark  .constraint.”  in  this 
♦lile,  and  "type.meirk"  in  the  AFIT  lile. 

♦ 

♦In  production  lor  conliguration.specilication,  "Identilier"  (AFIT)  has  been 
♦replaced  by  "name"  in  this  lile  in  accordance  with  the  LRM  delinition. 

* 

♦In  production  lor  entity .aspect,  "EHTITY  Identilier"  (AFIT)  has  been 
♦replaced  by  "EITITY  name"  as  per  the  LRM,  but  "COHFIGURATIOI  name"  (LRM) 

♦has  been  replaced  by  "COIFIGURATION  Identilier",  here,  as  sell  as  in  AFIT  lile. 
♦ 

♦Missing  Semicolon.ERR  in  production  lor  disconnection.specilication  in  AFIT 
♦lile  has  been  set  right. 

♦ 

♦In  production  lor  name,  "indexed.name"  includes  "slice.name" .  Besides, 

♦name  ->  operator.symbol  (operator  overloading)  has  not  been  implemented, 
♦(causes  28  reduce/reduce  conflicts). 

♦ 

♦prelix  ->  lunction.call  is  not  implemented,  "lunction.call"  is  handled  by 
♦"indexed.name" . 

♦ 

♦sullix  ->  operator.symbol  is  not  implemented. 

♦ 

♦  indexed.name  ->  prelix  (  expression  ,{  expression  }  )  in  LRM  is  implemented 
♦here  as  indexed.name  ->  name  aggregate. 

♦ 

♦In  production  lor  attribute.name,  "prelix"  (LRM)  is  replaced  by  "name", 

♦and  optional  expression  ’)’  in  LRM  is  implemented  as  ".aggregate." 

♦here . 

* 

♦"attribute.designator  ->  simple.name  I  RAHGE"  includes  the  keysord  "RARGE" 
♦here,  (used  as  an  Identilier  here). 

* 

♦In  production  lor  primary,  "lunction.call"  is  handled  by  "name",  and  ’(' 
♦expression  ')’  is  handled  by  aggregate.  Besides  primary  ->  type.conversion 
♦is  not  implemented. 

♦ 

♦literal  ->  Identilier  is  not  implemented,  (causes  99  reduce/reduce  conllicts). 
♦ 

♦Production  lor  element.association  contains  "simple.expression  direction 
♦simple. expression  I  name  range.constraint"  to  compensate  lor  change  in 
♦production  lor  "choice". 
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* 

^choice  ->  discrete.range  has  been  replaced  by  "choice  ->  simple.expression 
■•■direction  simple.expression  I  name  range_constraint" ,  since  "discrete.range 
♦->  subtype.indication  I  range"  causes  conflicts.  Besides  "choice  -> 
■•■simple.expression  I  simple.name"  has  been  replaced  by  "choice  -> 
*simple_expression"  since  "sinple.expression"  contains  "simple .name"  in  LRN 
^definition. 

* 

*function_call  is  handled  by  "indexed.name" 

* 

*In  production  for  qualified.expression,  "type.mark"  has  been  replaced  by 
e"name" .  and  "aggregate"  includes  ’ ( *  expression  * ) ’ . 

* 

■^"type.conversion"  has  been  replaced  everywhere  by  its  appropriate 
♦production. 

e 

♦allocator  ->  lEW  subtype.indication  I  lEV  qualified. express ion  has  been 
♦replaced  by  "lEU  qualif ied.expression"  only,  since  "subtype. indication" 
♦causes  conflicts. 

* 

♦  .AFTER _ expression.  ->  1  AFTER  numeric.literal  (AFIT)  has  been  changed  to 

♦".AFTER _ expression.  ->  I  AFTER  expression”  to  reflect  the  LRM. 

* 

♦In  production  for  procedure.call.statement ,  "actual.parameter.part"  has 
♦been  ommitted.  Its  inclusion  causes  1  shift/reduce,  and  2  reduce/reduce 
♦conflicts.  Here,  procedure.call.statement  has  been  implemented  as  "name 
♦Semicolon.ERR" ,  since  "name"  includes  "name  aggregate". 

<* 

♦In  production  for  component.instantiation.statement,  "Identifier"  (AFIT) 

♦has  been  replaced  by  "name"  as  per  the  LRM  definition 

e 

♦generate.statement  is  always  labelled  (LRM).  So  unlabelled.generate.statement 
♦(AFIT)  is  not  implemented. 

* 

♦Missing  Semicolon.ERR  in  production  for  library.clause  in  AFIT  file  has 
♦been  set  right. 

* 

* 

■*«♦♦♦♦♦♦♦*♦♦♦♦♦♦♦♦♦♦♦♦■•>♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦/ 

/♦ 

♦♦  $Header:  vhdl.y,v  4.0  87/11/30  15:58:01  rbratton  Exp  $<y.op>$<y.op>$ 

** 

♦♦  $Log;  vhdl.y,v  $<y.op>$<y.op>S 

♦  Revision  4.0  87/11/30  15:58:01  rbratton 

♦  Check  in  of  VHDL  version  4.0  (version  reported  in  thesis). 

♦ 

♦  Revision  3.2  87/11/04  16:10:48  rbratton 

♦  Parser:  corrected  ranges  and  aggregate  grammar.  1  shift/reduce 

♦  conflict. 

♦  Lex:  Save  before  trying  to  implement  alternate  replacement 

♦  characters  (!  for  I,  :  for  #,  and  '/.  for  ") . 
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*  Revision  3.1  87/11/01  11:28:31  rbratton 

v  Checkpoint  save  before  trying  to  resolve  "range”  problems. 

* 

*  Revision  3.0  87/10/15  06:23:49  rbratton 

*  Beta  3  Save.  Implemented  case/selected  signal  assignment  and 

*  aith/use  (using  improved  symbol  table). 

* 

*  Revision  2.3  87/10/11  15:06:54  rbratton 

*  Because  of  problems  vith  passing  floating  point  parameters,  floating 

*  point  has  been  removed — replaced  vith  integer  long.  Hopefully,  at  a 

*  later  time,  the  problems  will  be  resolved. 

*  This  is  also  a  configuration  save  before  adding  WITH/USE  capabilities 

*  to  the  analyzer. 

* 

*  Revision  2.2  87/09/06  20:05:55  rbratton 

*  Checkpoint  save  before  implementing  improved  s3nnbol  table. 

* 

*  Revision  2.1  87/09/01  11:26:46  rbratton 

*  Implemented  floating  point  notation.  Uses  float  (32  bits?)  rather  than 

*  double,  but  could  possibly  be  changed  later. 

* 

**  Revision  2.0  87/08/29  09:43:08  rbratton 

**  Configuration  save.  For  VHDL  Release  2.0 
** 

**  Revision  1.8  87/08/24  18:30:11  rbratton 

**  1  shift/reduce  conflict  (default  acceptable).  Creates  487  cases. 

♦♦  Changed  value  of  lULL.SYNBOL  from  (struct  sym.entry  *)  0  to 
**  HULL  (=  0).  Still  creates  a  HULL  pointer,  but  does  not  generate 
**  warnings  while  compiling  the  resulting  code  (vhdlyacc.c) . 

** 

**  Revision  1.7  87/08/18  19:35:46  rbratton 

**  Corrected  problems  with  signal  assignment  statement.  Added  labels  to 
**  block  statement  and  label  symbol  table  entry. 

** 

**  Revision  1.6  87/08/09  19:34:47  rbratton 

**  This  version  will  NOT  compile.  It  causes  a  "switch  table  overflow". 

**  The  next  version  may  be  a  reduced  grammar  to  try  to  avoid  this 
♦♦  problem. 

** 

**  Revision  1.5  87/07/18  19:14:53  rbratton 

**  checkpoint  save:  no  conflicts 
** 

♦*  Revision  1.4  87/07/17  18:21:23  rbratton 

**  checkpoint  save:  9  shift/reduce  conflicts 
**  Plus/Minus  LeftParen 
** 

**  Revision  1.3  Z7/Q7I\1  17:67:60  rbratton 

**  checkpoint  save:  13  shift/reduce  conflicts 
**  Plus/Hinus;  Identifier 
** 
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♦*  Revision  1.2  87/07/15  10:07:55  rbratton 

*<t>  checkpoint  save 
** 

**  Revision  1.1  87/06/21  09:24:24  rbratton 

Added  some  error  recovery.  More  to  folios, 
ee 

Revision  1.0  87/04/24  17:28:14  rbratton 
**  Initial  revision 
ee 
ee 
*/, 


V.i 


♦include  <malloc.h>  /*  !!!!!!  For  BISOH  CODE  !!!!!!*/ 

♦include  <stdio.h> 

♦include  <conio.h> 

♦include  <stdlib.h> 

♦include  "comp.h" 

♦include  "arch.h" 

♦include  "misc.b" 

♦include  "signal. h" 

♦include  "process. h" 

♦include  "ident.h" 

♦include  "comp.in.h" 

♦include  "portoap.h" 

♦include  "assoc. h" 

♦include  "thesis.h" 

♦include  "ncode.h" 

♦include  "entity. h" 

♦include  "port.h" 

♦include  "generate. h" 

♦include  "vhdl.hpp" 

int  G_translate  =  TRUE;  //  Translate  signal  IDs  to  offsets  if  TRUE 

extern  int  ANY_HANE;  /*  generic  hash  table  index  for  error  recovery  */ 
int  opl,  op2,  op3;  /♦  temporary  variables  for  op  indices  ♦/ 

int  is.childless;  /♦  attribute  of  architecture  body  */ 
int  is_structure;  /*  attribute  of  architecture  body  */ 

%y 

%union  { 

int  y_tok;  /*  token  */ 
int  y_op;  /*  Index  to  op  table  entry  */ 
int  y.hash;  /*  Index  to  hash  table  entry  */ 
int  y_8tr;  /♦  Index  to  string  storage  */ 
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/♦SYM_PTR  y_syin:*/  /*  Pointer  to  symbol  table  entry  */ 
long  y_val;  /*  Floating  point  number  (32  bits)  */ 
t*  (also  hemdles  integer  values)  */ 

} 

I*  terminal  symbols  */ 

/*  old  terminal  symbols  -  keep  until  removed  from  yacc  code  *! 


/♦‘/.token  *k’  */ 
‘/(token  Apostrophe 
/♦Xtoken  '('*/ 
/♦%token  RightParen*/ 
Xtoken  DoubleStar 
/♦%token  Star  */ 
/♦‘/.token  ’  +  '  ♦/ 
/♦‘/.token  ’ ,  ’  ♦/ 
/♦)(token  ♦/ 

Xtoken  VarAsgn 
/♦iitoken  ’ :  ’  ♦/ 
/♦‘^token  Semicolon  ♦/ 
%token  LESym 
Xtoken  Box 
/♦‘/.token  ’<'  ♦/ 

‘/.token  Arrow 
/♦‘/.token  ♦/ 
‘/.token  GESym 
/♦‘/.token  ’>’  ♦/ 
‘/.token  Bar 
‘/.token  lESym 
/♦‘/.token  ’ .  ’  ♦/ 
Ktoken  Slash 
%token  Identifier 
Xtoken  Decimallnt 
%token  DecimalReal 
%token  Basedint 
Xtoken  BasedReal 
Xtoken  CharacterLit 
‘/.token  StringLit 
‘/.token  BitStringLit 
‘/(token  ABS 
‘/.token  ACCESS 
‘/.token  AFTER 
‘/.token  ALIAS 
((token  ALL 
‘/.token  AID 
‘/.token  ARCHITECTURE 
y.token  ARRAY 
‘/.token  ASSERT 
‘/.token  ATTRIBUTE 
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'/.token  BEGIK. 

%token  BIT 
Xtoken  BLOCK 
'/.token  BODY 
'/.token  BUFFER 
'/.token  BUS 
Ktoken  CASE 
'/.token  CONPOIENT 
'/.token  CORFIGURATION 
'/.token  CONSTAIT 
'/.token  DISCORIECT 
'/.token  DOWITO 
^token  ELSE 
'/.token  ELSIF 
'/.token  EID_ 

'/.token  EITITY 
'/.token  EXIT 
'/.token  FILE. 

Xtoken  FOR 
'/.token  FUNCTION 
'/.token  GENERATE 
'/.token  GENERIC 
'/.token  GUARDED 
'/.token  IF 
'/.token  INOUT 
'/.token  IN 
'/.token  IS 
'/.token  LABEL 
'/.token  LIBRARY 
'/.token  LINKAGE 
Xtoken  LOOP 
%token  MAP 
'/.token  MOD 
^token  NAND 
'/.token  NEW 
'/.token  NEXT 
'/.token  NOR 
'/.token  NOT 
'/.token  NULL. 

'/.token  OF 
'/.token  ON 
y.token  OPEN 
y.token  OR 
'/.token  OTHERS 
'/.token  OUT 
'/.token  PACKAGE 
'/.token  PORT 
'/.token  PROCEDURE 
'/.token  PROCESS 
'/.token  RANGE 
%token  RECORD 


’/.token 

REGISTER 

’/.token 

REM 

’/.token 

REPORT 

Xtoken 

RETURN 

Xtoken 

SELECT 

’iCtoken 

SEVERITY 

Xtoken 

SIGNAL 

’/Ctoken 

SUBTYPE 

Xtoken 

THEN 

*4token 

TO 

y.token 

TRANSPORT 

%token 

TYPE 

%token 

UNITS 

ytoken 

UNTIL 

’/.token 

USE 

’/.token 

VARIABLE 

’/.token 

WAIT 

%token 

WHEN 

ytoken 

WHILE 

’/token 

WITH 

’/token 

XOR 

**  operator  precedences  and  associativities  listed  in 
**  increasing  precedence. 

>•>*  lote:  ABS  and  HOT  have  the  sane  precedence  as  DoubleStar; 

**  yet,  they  associate  to  the  right.  The  (non)token  UNARY.SIGH  is  used 
**  only  to  establish  precedence  lor  unary  plus/minus  signs.  It  does  not 
**  have  to  be  a  declared  token  or  have  any  other  value  other  than  its 
**  relative  precedence  value. 

** 


‘/.left  AMD  OR  HARD  NOR  XOR 

•/.left  '='  lESym  ’<•  LESyn  ’>'  GESyn 

•/.left  '  +  ' 

’/.left  Slash  MOD  REM 
•/.right  UMARY.SIGH 
’/left  DoubleStzo: 

•/.right  ABS  HOT 

•/.{ 

»ifndel  HDEBUG 

•define  TRACE(x,z)  {il(yaccdebug)printf ("#RULE  %s  ::=  •/.s\n",x,2);} 
•else 

•define  TRACE(x,z)  ; 

•endif 

•/.} 
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/* 

*  start  s3nnbol  =  "design.lile 
*/ 

Xstart  design.lile 

/* 

*  Rules 
*/ 

VI. 


/* 

**  Chapter  1:  Design  Entities 
*/ 

/*  1_1  ♦/ 

entity.decleuration 
:  EITITY 
i 
} 

Identifier 

entity_add() : 

} 

IS 

_generic_clause_ 

port.clearO ; 

} 

_port_clause_ 

•C 

entity_add_port() ; 

> 

ent ity_declarat i ve_part 

_BEGII _ entity_statement_part 

EHD.ERR 

_simple_name_ 

Semicolon.ERR 
I  EITITY  error 


/♦  1_1_1  */ 
_port_clause_ 
:  /eempty*/ 

I  port.clause 


_generic_clause_ 
:  /eempty*/ 

I  generic.clause 


port.clause 
:  PORT 

lormal_port_list 

RightParen.ERR 

Semicolon.ERR 


generic.clause 
:  GEIERIC 

lonnal_generic_list 

RightParen.ERR 

Semicolon.ERR 


/*  •/ 
f ormal_port _1 ist 
:  fornal.poTt.element 

_ foraal.port.element _ 

I  arror  RightParen.ERR 


_ lomal.port.eleBent _ 

:  /♦empty*/ 

I  _ formal.port.element _ 

Semicoloa.ERR 

formal.port.elemant 

yyerrok; 

} 


1 ormal.port .element 
:  .SIGIAL. 

i 

ident.list.clearO : 

> 

ident il ier.l ist 

>  .  I 

.mode. 

/♦  .name,  causes  conflict  */ 

type.mark 

.constraint. 

-BUS. 

{ 

port.add.id.listO : 


} 


.VarAsgn _ expression. 


.SIGIAL. 

:  /*enipty*/ 
I  SIGNAL 


.mode. 

; /♦empty*/ 

I  IN 

{ 

direct_set(V_II) ; 

} 

I  OUT 

i 

direct_6et(V_0UT) ; 

} 

I  IIOUT 
I  BUFFER 
I  LINKAGE 


.BUS. 

:  /*empty*/ 
I  BUS 


.VarAsgn _ expression. 

:  /*empty*/ 

I  VarAsgn 
expression 


/*  1.1. 1.1  */ 
formal .generic.list 
:  formal.generic.element 

_ formal .generic.element 

I  error  RightParen.ERR 


_ formal.generic.element _ 

:  /*empty*/ 

I  _ formal.generic.element 

Semicolon.ERR 

formal.generic.element 

{ 

yyerrok ; 


} 


1 ormal.gener i c_  element 
:  _CONSTAIT_ 
identif ier.list 


/♦  _name_  causes  conflict  ♦/ 

type_mark 

_constraint_ 

JVaxksga _ expression. 


_COBSTAIT_ 

:  Z+empty*/ 
I  COISTANT 
* 

-I*. 

:  /♦empty ♦/ 
I  IN 


/*  1.1_2  ♦/ 

entity_declarative_pairt 
:  _ entity_declarative_item _ 


_ entity_declarative_item _ 

:  /*empty^/ 

I  _ entity_declarative_item. 

entity_declarative_item 


entity.declarative.item 
:  alias.declaration 
I  constant .declaration 
I  type.declaration 
I  subtype.declaration 
I  attribute.declaration 
I  attribute.spccification 
I  subprogram.declaration 
I  subprogram.body 
I  signal.declaration 
I  lile.declaration 
I  disconnection.specification 
I  use.clanse 
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/*  1_1_3  •/ 


_BEGII _ entity_statement_part 

:  /♦  empty  ♦/ 

I  BEGII_ 

entity_statement_part 


entity.statement.pairt 
:  entity .statement. 


_ entity.statement _ 

:  /eempty*/ 

I  _ entity.statement _ 

entity.statement 


ent ity.statement 
:  concurrent.assertion.statement 
i  concurrent.procedtxre.call 
I  process.statement  /*  HOT  IH  7.2  */ 


/*  1.2  */ 

/*  architecture  bodies  */ 

architecture.body 
:  ARCHITECTURE 

} 

Identifier 

{ 

arch.addO ; 

} 

OF 

name  /*  entity  name  */ 

{ 

arch.name ( ) ; 

} 

IS 


signal. clear.list () ; 
comp.clear.list ( ) ; 
comp. inst. list. clearO ; 
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} 

architecture_declarative_p2irt 

BEGIH. 

architecture_statement_part 

END.ERR 

_simple_najae_  /*  architecture  simple  name  */ 
Semicolon.ERR 
1  ARCHITECTURE  error 
• 

/*  1_2_1  */ 

/*  Architecture  Declarative  Part  */ 
architecture_declarative_part 
:  _ block_declarative_item _ 


_ block_declarative_item _ 

:  /♦empty*/ 

I  _ block_declarative_item _ 

block.declarat ive.item 


block.declarative.item 
:  constant.declaration 
I  signal.declaration 
{ 

arch.add.signal.listO ; 

} 

I  tjrpe.declaration 
I  subtype.declaration 
I  attribute_declaration 
I  component_declaration 
{ 

arch_add_comp_list() ; 

} 

I  alias .declaration 
I  attribute.specilication 
I  configuration.specification 
I  subprogram.declaration 
I  subprogram.body 
I  f ile.declaration 
I  disconnection.specif ication 
I  use.clause 

f 

/*  1.2.2  ♦/ 

/*  Architecture  Statement  Part  ♦/ 
architecture.statement.part 
:  _ concurrent. statement _ 
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/♦  1_3  */ 

conf iguration.declaration 
:  COIFIGURATIOI 

> 

Identifier 

i 

generate_got_top_id( ident.get  ( ) ) 

> 

OF 

name  /*  Identifier  */  /*  entity.name  */ 

■C 

generate_got_top_ent ity.id ( ident_get ( ) ) 

} 

IS 

conf igurat ion.declarat ive.part 
block. conf igurat ion 
EHD.ERR 
_simple_name_ 

Semicolon.ERR 
I  COMFIGURATIOW  error 


conf igurat ion.declarat ive.part 
:  conf iguration.declarative.item 


_ conf  igurat  ion.declzirat  i ve_  it  em _ 

:  /♦empty*/ 

I  _ conf iguration.declarative.item. 

conf igurat ion.declarat ive_ item 


conf igur at ion.declarat i ve_ it  em 
:  use.clause 

I  attribute.specif ication 


/*  1_3_1  ♦/ 

/*  block  configuration  */ 
block. conf igurat ion 
:  FOR 

block.specif icat ion 

{ 

generate.got.top.arch.id(ident.get() ) ; 

> 

_ use.clause _ 

_ conf igurat ion. it  em _ 

ERD.ERR 

FOR 
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Semicolon.ERR 


_ use. clause _ 

:  /♦empty*/ 

I  use.clause 
_ use.clause _ 


_ conliguration.item _ 

:  /♦empty*/ 

1  coni iguration_item 

conf igurat ion_ it  em 


block.specilication 
:  label  /♦  arch,  block,  generate  ♦/ 
_opt_index_spec_ 

/♦  I  name  causes  conflict  ♦/ 


_opt_index_spec_ 

:  /*empty*/ 

I  ’(' 

index.specification 

RightParen.ERR 


index.specilication 
:  discrete.range 
I  expression 


conf igurat ion.item 
:  block.conliguration 
I  component.conf igurat ion 


/♦  1_3_2  ♦/ 

component.conf igurat ion 
;  FOR 

instantiation.list 

>  .  I 

name  /♦  Identifier  ♦/ 

_USE _ binding. indication. 

.block.conf iguration. 

EHD.ERR 

FOR 
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< 

generate_ident_list() ; 

} 

Semicolon.ERR 


_USE _ binding. indicat ion_ 

:  /*empty*/ 

I  USE 

binding. indi cation 
Semicolon.ERR 


.block. coni igurat ion. 
:  /*empty*/ 

I  block.conliguration 


I* 

**  Chapter  2:  Subprograms 
*/ 

/*  2.1  */ 

subprogram.declarat ion 
:  subprogram.specif ication 
Semicolon.ERR 


subpr ogr  sun.spe  c il icat ion 
:  PROCEDURE 
designator 

.procedure.parameter.list, 
I  FUHCTIOH 
designator 

.function.parameter.list. 

RETURN 

type .mark 


designator 
:  Identifier 
I  operator.symbol 


operator.symbol  /*  defined  in  LRM  2.1  ♦/ 
:  relational.operator 
I  adding.operator 
/*  I  sign  */ 

I  multiplying. operator 
I  logical.operator 
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I  miscellaneous.operator 
I  StringLit 

I 

logical.operator  ;  AID  I  OR  I  NAHD  |  NOR  |  XOR 

9 

miscellaneous.operator  :  DoubleStar  I  ABS  I  lOT 


_procedure_paraineter_list_ 

:  /♦empty*/ 

I  '(' 

procedure_parameter .element 

_ procedure.parameter.element 

RightParen.ERR 

I 

error 

RightParen.ERR 


_ procedure.parameter.element _ 

:  /•empty*/ 

I  _ procedure.parameter.element _ 

Semicolon.ERR 

procedure.parameter.element 

{ 

yyerrok ; 

> 


procedure.parameter.element 
:  .procedure.parameter.object. class, 
identilier.list 

I  .  A 

_procedure.parameter.mode. 

/*  .name,  causes  conflict  */ 

type.mark 

.constraint. 

.VeirAsgn _ expression. 


.procedure.paarameter.object.class. 
:  /*empty*/ 

I  VARIABLE 
1  COHSTANT 


.procedure.pearameter.mode. 
:  /*empty*/ 

I  IN 
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I  OUT 
I  IIOUT 


_fiuiction_parameter_list_ 

:  /♦empty*/ 

I  ’(' 

function.parameter.elenent 

_ lunction_paraneter_elenent 

RightParen.ERR 

I  '(' 

error 

RightParen.ERR 


_ lunction.parameter.element _ 

:  /*eBpty*/ 

I  _ lunction.parameter.element 

Semicolon.ERR 

lunction.parameter.element 


lunction.parameter.element 
:  .lunction.parameter.object.class. 
identilier.list 

J  .  I 

.lunct ion_parameter_mode. 

type.mark 

.constraint. 

.VarAsgn _ expression. 


.lunct ion.parameter. object. class 
:  /eempty*/ 

I  COHSTAIT 
I  SIGHAL 


.lunct ion.parameter .mode 
:  /eempty*/ 

I  II 


/♦  2.2  */ 

subprogram.declarative.part 
:  /eempty*/ 

I  subprogram.declarative.part 
subprogram.declarative.item 


{ 

yysrrok ; 

} 


subprograB_decl2urative_item 
:  constant_decl2u:ation 
I  variable.declaration 
I  alias.declaration 
I  typa.declaration 
I  subtype.daclaration 
I  attribute.daclaration 
I  attribute.specilicatioii 
I  sabprograa_declaration 
I  subprogran.body 
I  file.declaration 
I  use_clause 


/*  2_2  */ 

/*  subprogram  bodies 

subprograa.body 
:  subprogram.specilication 
IS 

subprogram.declarat ive.part 
BE6II_ 

sequence.ol.statements 

END.ERR 

_designator_ 

Semicolon.ERR 


.designator. 
:  /fempty*/ 

I  designator 


/*  Packages  */ 

/*  2.6  */ 

pack?  ge.declarat ion 
:  PACKAGE 
Identifier 
IS 

package.declarative.part 

END.ERR 

.simple.name. 
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Semicolon.ERR 
I  PACKAGE 
error 


package.declarat ive.part 
:  _ package_declarative_item__ 


_ package.declarative.item _ 

:  /*empty*/ 

I  _ package_declarative_item__ 

package_declarative_item 


package_declarative_item 
:  type.declaration 
I  subtype.declaration 
I  attribute.declaration 
I  constant_declaration 
I  alias.declaration 
I  subprogram.declaration 
I  component.declaration 
I  attribute.specilication 
I  signal.declaration 
I  file.declaration 
I  disconnection.specilication 
I  use.clause 
I  error  EID.ERR 
Semicolon.ERR 


/*  2_6  */ 

/*  package  bodies  *! 

package.body 
:  PACKAGE 
BODY 

Identifier 

IS 

package_body_declarat ive.part 

END.ERR 

_siinple_name_ 

Semicolon.ERR 
I  PACKAGE 
BODY 
error 


package_body_declarative_part 
:  _ package_body_declarative_item_ 


_ pacXage_body_declarative_item _ 

:  /*empty*/ 

I  _ package_body_declaurative_item. 

package_body_decl2u:ative_item 


package_body_declarative_item 
:  subprogram.declaration 
I  subprogram.body 
I  type_decleu:ation 
I  subtype.declaration 
I  constant_declaration 
I  file.declaration 
I  alias.declaration 
I  use.clause 


/* 

**  Chapter  3:  Types 
*/ 


/*  3_1  */ 

scalar_type_del init ion 
:  enumeration_type_def init ion 

I  range_type_def init ion  /*  includes  integer  and  floating  point  */ 
I  physical_type_def inition 


range.constraint 
:  RARGE  . 
range 


range 

:  attribute_nzune  simple_expression  simple.expression  ->  (attribute)  neune 
I  simple_expression 
direction 
simple.expression 


direction 
:  TO 

I  DOURTO 


/*  ♦/ 

enuoeration.type.def inition 
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:  '(’ 

eniuieration.literal 

_ enunerat ion_l it  eral _ 

RightParen.ERR 


_ enunerat ion. 1 it  eral _ 

:  /eeaptye/ 

1  _ enunerat ion.l it eral 

9  9 

t 

enunerat ion.l iteral 

{ 

yyerrok; 

} 


enunerat ion.l it  eral 
:  Identifier 
I  CharacterLit 


/*  3.1.2  *  3.1.4  ♦/ 

/*  Integer  and  Floating  Point  types  */ 

range.ty pe.def init ion 
:  range.constraint 


/*  3.1.3  ♦/ 

phy 8 ical.type.def inition 
:  range.constraint 
UIITS 

base.unit. declaration 

_ secondary .unit .decleuration. 

EID.ERR 

UIITS 


_ secondary .unit.declarat ion _ 

:  / ♦empty*/ 

1  _ secondary.unit.declaration _ 

secondary .unit .declaration 

{ 

yyerrok; 

> 


base.unit.decleuration 
:  Identifier 
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Senicolon.ERR 


secondary .unit _d«clarat ion 
:  Identifier 
>  =  > 

physical.literal 

Semicolon.ERK 


physical.literal 
:  _abstract_literal_ 
nase  /*  in  LRM:  UIIT.nane 


_abstract_literal_ 
:  /eenpty*/ 

I  abstract.literal 


/*  3_2  ♦/ 

compos it  e.type.def init ion 
:  array_type_definition 
I  record_type_definition 


/♦  3_2_1  ♦/ 
array.type.def inition 
:  unconstrained_array_del init ion 
I  constrained_array_definition 


unconstrained_array_del inition 
:  ARRAY 

index_subtype_del init ion 

_ indez_subt]rpe_def  init  ion _ 

RightParen.ERR 

OF 

subtype.indication 


_ index_8ubtype_del init ion _ 

:  / *empty*/ 

I  _ index_subtype_delinition _ 

9 

index.subtype.def inition 


constrained_aurray_del init ion 
:  ARRAY 

index.constraint 

OF 

subtype.indication 


index.subtype .definition 

:  name  /*  type.mark  -  canses  conflict  */ 
RANGE 
Box 


index.constraint 

discrete.range 

_ discrete.range _ 

RightParen.ERR 


_ discrete.range _ 

:  /*eiipty*/ 

I  _ discrete.range _ 

9 

discrete.range 

{ 

yyerrok; 

} 


discrete.range 

:  range  /*  includes  attribute.name  */ 

I  name 

range.constraint  /*  subtype.indication  -  causes  conflict  */ 
I  type.mark  /*  type.mark  causes  2  r/r  conflicts  -  required  for 
louie’s  code  */ 


/*  3.2.2  ♦/ 

r ecord.type.def init ion 
:  RECORD 

element .declaration 

_ element  .decleurat  ion _ 

EID.ERR 
RECORD 
I  RECORD 
error 
EID.ERR 
RECORD 
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_ element _declarat ion _ 

:  /*empty*/ 

I  element .decleo'ation 

element .declaration 

yyerrok ; 

} 


element .declaration 

:  identilier.list 

»  .  » 

element.subtype.def inition 
Semicolon.ERR 


/* 

**  identifier. list  is  used  consistently  in  definitions  of  nea  Identifiers, 

♦♦  with  one  exception — IMPORT.DIRECTIVE.  The  IMPDRT.DIRECTIVE  expects  to 

**  find  all  Identifiers  declsired  at  the  local  scope  and  it  is  am  error  if 

**  they  aire  not.  In  all  other  cases,  it  is  an  error  to  have  tvo  Identifiers 

**  with  the  same  name  at  the  same  level.  (Overloading  not  implemented.) 

**  Therefore,  identif ier.list  checks  to  see  if  the  previous  token  eas 
•*  IHPORT. 

**  returns  pointer  to  symbol  table  which  has  a  list  of  identifier 
**  definitions  connected  by  the  "next"  pointers. 

*/ 

identif ier.list 
:  Identifier 
{ 

ident.list.cleam’O ; 
ident.list.addO ; 

#ifdef  _DB1_ 

puts("  Enter.id.listO") ; 

#endif 

} 

_ identifier _ 


_ identifier _ 

:  /*empty*/ 

I 

Identifier 

ident.list.addO ; 

#ifdef  .DBl. 

puts("  Enter.id.listO"); 
#endif 

} 
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_ identifier.. 


element.subtype.definition 
:  subtype.indication 


/♦  3_3  */ 

/*  Access  Types  */ 
access_type_definition 
:  ACCESS 

subtype.indication 


/♦  3_3_1  */ 

/’*'  IncoBplete  Type  Declarations  */ 
incomplete.type.declaration 
:  TYPE 
Identifier 
Semicolon.ERR 


/♦  3_4  */ 

/*  File  Types  ♦/ 
f ile_type_def inition 
:  FILE. 

OF 

type.aark 


/* 

**  Chapter  4:  Declarations 
*/ 

/*  4.1.1  */ 
type.declaration 
:  full.type .declaration 
I  incomplete.type.declaration 


full.type.declaration 
:  TYPE 
Identifier 
IS 

type.def inition 
Semicolon.ERR 


type.del init ion 
:  scalar_type_del init ion 
I  composite_type_definition 
I  access_type_definition 
I  lile_type_del init ion 
I  error  Semicolon.ERR 

I 

/*  4_2  ♦/ 

subtype.declaration 
:  SUBTYPE 
Identifier 
IS 

subtype.indication 

Seaicolon.ERR 


subtype.indication 
:  type_or_function_najne 
type.mark 
_constraint_ 

I  type.Bark 
_con8traint_ 


.constraint. 
:  /*empty*/ 

I  constraint 


type.or_fnnction.name 
:  expanded.name 


expanded.name 

:  simple.name  f*  Identifier  */ 

/*  I  STAIDARO 
*/ 

I  expanded.name  f*  nas  Identifier 

9  9 

simple.name  /*  Identifier  */ 

i 

yyerrok ; 

} 


/* I !  •  M  •  I  I  j  I  j  !  CHARGED  !!!!!!!!!!!!!!!! 

! type .mark 

!  ;  expanded_name  /  *  move  to  production.c  ! ! !  *  / 
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I 


!  /  *  type.fflark  and  constraint 
!  nill  othersise  cause  conflict  e  / 

t 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/ 
type_mark 
:  BIT 

type_set(V_BIT) ; 

}  /*  Only  allow  BIT  types  at  this  time  e/ 


/4i ! j  !!!!!!!!!!  !  EBD  CHANGE  !!!!!!!!!!!!!*/ 

constraint 
:  range.constraint 

I  aggregate  /•  was:  (  discrete.range  _ discrete_range _  )  ♦/ 

/*  index.constraint  */ 


/*  4_3_1_1  ♦/ 

constant .declaration 
:  CONSTANT 
identifier.list 

I  «  > 

subtype.indication 

_VarAsgn__oxpression_ 

Semicolon.ERR 


/*  4_3_1_2  ♦/ 
signal.declaration 
:  SIGNAL 

•C 

idont_list_clear() ; 

> 

identif ier.list 

I  .  I 

subtype.indication 

_signal_kind_ 

signal_add_id_list() ; 

} 

.VarAsgn _ expression. 

Semicolon.ERR 


.signal.kind. 
:  /eempty*/ 

I  signal.kind 
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signal .kind 
:  REGISTER 
I  BUS 


/*  4_3_1_3  ♦/ 
variable.declaration 
:  VARIABLE 
identilier.list 

f  «  > 

subtype.indication 

.VarAsgn _ expression. 

Semicolon.ERR 


/*  4.3.2  */ 

/*  File  Declarations  */ 
f ile.declaration 
:  FILE. 

Identifier 

>  .  A 

subtype.indication 

IS 

.mode. 

expression 

Semicolon.ERR 


/♦  4.3.3  and  4_3_3_1  */ 

/*  Interface  Declaration  and  lists  are  interspersed 

shere  they  are  actually  used  port,  generic  and  parameter  */ 

/♦  4.3.3.2  ♦/ 

/*  Association  lists  *! 

association.list 
:  association.element 
_ association.element _ 


_ association.element _ 

:  /♦empty*/ 

1 

association.element 

_ association.element. 

{ 

yyerrok; 

} 
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/♦ 

**  (  expression  )  is  defined  by  aggregate  as: 

**  (  general_eleinent_association  )  => 

**  (  OPEM_or_expression  )  => 

(  expression  ) 

*/ 

association.element 

:  /•  formal_part  */  /*  causes  conflict  ♦/ 

name 

{ 

assoc_list_add_node() ; 
assoc_left(ident_get()) : 

} 

Arros 
{  . 

mcode_clear_list ( ) ; 

G.translate  =  FALSE;  //  Stop  translating  signals  to  offsets 

} 

/*  actual_part  ♦/ 

OPEH_or_expression  /*  can  be  name  also  */ 

{. 

int  signal.name; 
mcode_c_pop_top() ; 
signal.name  =  mcode_c_pop() ; 
assoc_right(signal_name) ; 

G.translate  =  TRUE;  //  Start  translating  signals  to  offsets 

} 

I  /*  actual.part  •/ 

OPEH_or_expression  /*  can  be  name  also  */ 

I 

/*  causes  conflict 

formal.part  :  name  I  name  name  ')' 

t 

actual_p2urt  :  OPER_or_expression  I  name  ’(’  OPEH_or_expression 

I 

*/ 

OPElI_or_expression 
:  OPEN 

I  expression 


/♦  4_3_4  */ 
zdias.declaration 
:  ALIAS 

Identifier 

>  •  > 

subtype.indication 

IS 

name 
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Semi colon_ERR 


/♦  4_4  ♦/ 

attribute.declaration 
:  ATTRIBUTE 
Identifier 

9  •  9 

type.mark 

Semicolon.ERR 


/*  4_5  */ 

component .declaration 
:  COMPONEHT 
Identifier 

comp_add_comp() ; 

} 

.GEHERIC _ local_generic_list 

.PORT _ local_port_list_ 

{ 

comp_add_port() ; 

} 

ElO.ERR 
COMPOHEIT 
Semi col on.ERR 


.PORT _ local.port.list. 

:  /*emptye/ 

I  PORT 

port.clearO ; 

} 

local.port.list 

RightParen.ERR 

Semicolon.ERR 


local.port.list 
:  local.port. element 

_ local.port.element _ 

I  error  RightParen.ERR 


.local.port.element _ 


:  /♦empty*/ 

I  _ local_port_elemert 

Semicolon.ERR 

local_port_element 


local_port .element 
:  _SIGIAL_ 

ident_list_clear() ; 

} 

ident if ier_l ist 
>  .  1 

_local_port_mode_ 

type.mark 

port_add_id_li8t() ; 

> 

.constraint. 


_local.port.mode. 

:  /fempty*/ 

I  IN 

{ 

direct_8et(V_II) ; 

} 

I  OUT 

{ 

direct_set(V_OUT) ; 

> 

I  INOUT 
I  BUFFER 
I  LINKAGE 


.GENERIC _ local.generic.list. 

:  /*empty*/ 

I  GENERIC 

local.generic.list 

RightParen.ERR 

Semicolon.ERR 


local_gener ic.l ist 
:  loceQ_generic_element 

_ local_generic_element _ 

I  error  RightParen.ERR 


_ local_gen«ric_element _ 

:  /♦empty*/ 

I  _ local_generic_element _ 

Semicolon.ERR 

local_generic_element 


local_generic_elemeiit 
:  _COISTAIT_ 
ident il ier.list 

I  •  > 

type.mark 

_constraint_ 


/♦ 

♦♦  Chapter  6:  Specifications 
♦/ 

/♦  5.1  */ 

attribute.specif ication 
:  ATTRIBUTE 
attr ibnte.des ignator 
OF 

entity.specif ication 
IS 

expression 

Semicolon.ERR 


entity.specif ication 
:  entity.name.list 

I .  > 

entity .class 


entity.class 
:  EITITY 
I  ARCHITECTURE 
I  PACKAGE 
I  FUICTIOI 
I  PROCEDURE 
I  SUBTYPE 
I  COISTAIT 
I  VARIABLE 
I  SIGIAL 


I  LABEL 
I  TYPE 

I  COHFIGURATIOH 
I  COMPOIEHT 


entity.name.list 
:  entity.designator 

_ ent ity.des ignator _ 

I  OTHERS 
I  ALL 


_ entity.designator _ 

:  /*empty*/ 

I  _ entity_designator _ 

>  I 
» 

ent ity.des ignator 


ent ity.des ignator 
:  simple.naiBe 
I  operator.symbol 


/*  6_2  ♦/ 

conf igurat ion_specif icat ion 
:  FOR 

instantiation.list 

ident_c_list_print() ; 

} 

I  .  f 

/♦  Identifier  */ 

name 

USE 

binding. indication 
Semicolon.ERR 
I  FOR 
error 

Semicolon.ERR 


instant iat ion.l ist 
:  identifier.! ist 
I  OTHERS 
I  ALL 

I  error  ' : ’ 

{ 

yyerrok ; 


} 


/♦  6_2_1  ♦/ 
b inding. indicat ion 
:  entity.aspect 
_generic_map_aspect_ 
_port_niap_aspect_ 


I*  5_2_1_1  */ 
entity_aspect 
:  EITITY 

/*  Identifier  *! 

I*  name  /  *  name  causes  1  s/r  conflict  *! 

Identifier 

{ 

generat  e_ent it  y _name ( ident  _get () ) ; 

> 

_architecture_identifier_ 

{ 

generate.arch.name ( ident_get ( ) ) ; 

} 

I  CORFIGURATiaN 
Identifier 

/e  name  causes  conflict  */ 

{ 

printfC'!!!!  HOT  IMPLEMENTED  !!!!!!!  %d\n'',  ident  _get  ()) ; 

} 

I  OPEH 


_arcliitecture_identif  ier_ 
;  /^empty*/ 

I  ’(’ 

simple_nanie 

RightParen.ERR 


/♦  entity_indication 
:  librsu:y_name  entity  library_name 
I  OPEH 
:  */ 

/♦  5_2_1_2  */ 

_ element .association _ 

:  /eempty*/ 

I  _ element.association _ 
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element.association 

{ 

yyerrok ; 

> 

» 

/♦  6_3  */ 

/*  Disconnection_specilication  */ 
disconnection.specif ication 
:  DISCOMIECT 

guarded_signal_specil ication 

AFTER 

expression 

Semicolon.ERR 


guarded_signal_specif ication 
:  signal.list 

i  .  > 

type_mark 


/♦  6_2_3  */ 

/♦  initialize.directive 
:  IIltlALIZE 
type_Bark 
TO 

expression 

_ waveform. 

Semicolon.ERR 
;  */ 

/* 

**  Chapter  6:  Names 
*! 

/*  6_1  ♦/ 

/* 

**  According  to  the  VHDL  Test  suite,  library  names  are  not  used 
♦♦  in  expressions.  Therefore,  the  choice  "library .name"  is  removed. 

♦♦  NEED  TO  CHECK  THIS  OUT!!!  */ 
name 

:  simple.name  /*  move  to  production.c  ♦/ 

I  indexed.name  /*  includes  "slice.name"  */ 

I  selected.name 

I  attribute.name  /*  not  implemented:  causes  2  reduce/reduce  conflicts. 
I  operator.symbol  overloading  not  implemented 
causes  reduce/reduce  conflicts  (28)  */ 
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prefix 

:  name  /lionet ion  call  handled  by  indexed.naae*/ 
/*  I  function_call 
*/ 


/*  6_2  */ 

sinple.name  /*  returns  hash  index  */ 

:  Identifier 


_simple_naine_ 
:  /♦empty*/ 

I  simple_name 


/♦  6_3  */ 
selected_nane 
;  prefix 

I  *  i 

suffix 


suffix 

:  simple.name 
I  CharacterLit 

/♦  I  operator.symbol  */  /*  handled  by  characterLit  */ 

I  ALL 


/♦  6_4  */ 

indexed.name  /♦  also  includes  "slice_name*'  6_5  */ 

:  name  /♦  in  LRM:  prefix  */ 

aggregate  /♦  in  LRN:  ’(’  expression  {  expression  } 

> 

/♦  6_6  */ 
attribute.name 

:  name  /*  prefix  causes  7  shift/reduce  conflicts  */ 
Apostrophe 
attr ibut  e_des ignator 

.aggregate.  /♦  in  LRM:  '(’  static.expression  ’)’  ♦/ 


.aggregate. 
:  /*empty*/ 
I  aggregate 


attribute_designator 

:  simple.nane  /*  attribute  simple.naae  */ 

I  RAHGE  /*  somebody  gooled!  Keysord  used  as  an  identilier  */ 

$ 

** 

**  Chapter  7  Expressions 
** 

/*  7_1  */ 
expression 

:  relation _ AND _ relation _ 

I  relation _ OR _ relation _ 

I  relation_HAND_IOR _ relation. 

I  relation _ XOR _ relation _ 


r elat ion _ AID _ r elat ion _ 

:  relation 
AID 

relation 

mcode_add(M_AID) ; 

} 

I  relation _ AID _ relation _ 

AID 

relation 

{ 

mcode_add(M_AID) ; 

} 

» 

relation _ OR _ relation _ 

:  relation 
OR 

relation 

mcode_add(N_OR) ; 

} 

I  relation _ OR _ relation _ 

OR 

relation 

{ 

mcode_add(M_OR) ; 

} 
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r elat ion.KAID.IOR _ relation. 

:  relation 
I  relation 

SAID 

relation 

{ 

mcode_add(N_HAHD) ; 

} 

I  relation 
lOR 

relation 

{ 

mcode_add(M_MOR) ; 

} 


relation _ XOR _ relation _ 

:  relation 
XOR 

relation 

{ 

mcode_add(K_XOR) ; 

} 

I  relation _ XOR _ relation _ 

XOR 

relation 

{ 

mcode_add(N_XOR) ; 

} 


relation 

:  simple.expression 
_r elop _ s imple.ezpr es  s ion_ 


_relop _ simple_expression_ 

:  / *empty*/ 

I  relational.operator 
s inpl e_ expr e s s ion 


/♦ 

*♦  simple.expression  ::=  [sign]  term  i  adding_operator  term  } 
*/ 

simple.expression 
:  _sign_term _ add.op _ term _ 
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relation_HAHD_HOR _ relation. 

;  relation 
I  relation 
RAHD 


relation 

{ 

mcode_add(N_HAKD) ; 

> 

I  relation 
HOR 

relation 

{ 

incode_add(H_IOR) ; 

} 


relation _ XOR _ relation. 

:  relation 
XOR 

relation 


i 

mcode_add(M.XOR) ; 

} 

I  relation _ XOR _ relation _ 

XOR 

relation 


{ 

mcode_add(M_XOR) ; 

} 


relation 

:  simple. express ion 
.relop _ s impl e.expr es  s ion. 


.relop _ simple.expression. 

:  /♦empty*/ 

I  relational.operator 
simple.expression 


/* 

♦♦  simple.expression  ::=  [sign]  term  -(  adding.operator  term  } 

*/ 

simple.expression 
:  .sign.term _ add.op _ term _ 
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term 
:  factor 
I  term 

mult iply ing_oper at or 
factor 

yyerrok; 

} 


_sign_term _ add_op _ term _ 

:  term  %prec  UIARY.SIGI 
I  sign 

term  */.prec  UIARY.SIGH 

I  _sign_term _ add_op _ term _ 

adding_operator 

term 


factor 
:  primary 

.DoubleStar _ primary. 

I  ABS 
primary 
I  lOT 
primary 
{ 

//  puts("  !  mcode_add(HOT)") : 
mrode_add(M_HOT); 

} 


.DoubleStar _ primary. 

:  Z+empty*/ 

I  DoubleStar 
primary 


primary 
:  literal 
{ 

mcode.adddit.get  0 ) ; 

> 

I  qu2dif ied.expression 
/♦  I  function.call 

*/ 

I  name  /*  name  =  simple.name  =  Identifier  =  enumeration.literal  «/ 
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if (G_translate  ==  TRUE  )  { 

TP_arch  arch_ptr  =  arch_get(arch_c_get_id()) ; 
TP_entity  ent_ptr  =  entity_get(2urch_ptr->na«e) ; 
TP_port  port_ptr  =  ent_ptr->port_list; 

TP_port  the_port  =  port_get(ident_get() ,  port_ptr); 

mcode_add(the_port->number) ;  //  Offset  of  the  port 

> 

else  { 

Bcode_add ( ident.get ( ) ) ; 

> 

BCode_add(M_GET) ; 

> 

/*  includes  function.call  */ 

I  aggregate  /*( express ion)  is  included  under  aggregate*/ 

/*  I  type.conversion  causes  reduce/reduce  conflicts 
*/  I  allocator 


/*  7_2_1  ♦/ 

/*  logical  operators  embedded  in  expression  */ 

/♦  7_2_2  */ 
r elat ional.oper at  or 

*  I  S  ^ 

I  RESym 
I  ’<’ 

I  LESym 
I  ’>’ 

I  GESym 


/*  7_2_3  */ 
add ing.operator 

I 

I  'ft' 


sign 
:  '  +  ' 
I 


/*  7_2_4  •/ 
multiplying. operator 

I  Slash 
I  MOD 
I  REM 
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/•  7_3_1  */ 
liter2d. 

:  numeric.literaG. 

I  CharacterLit 
/* 

*  I  eniuneration.literal 

*  Causes  99  reduce/reduce  conflicts  vith  Id  and  CharLit 

*  Covered  under  'na>ie'_ 

*/  /*  Identifier  causes  conflict  */ 

I  StringLit 
I  BitStringLit 
I  HULL_ 


ntuner  i  c  _  1  i  t  er  al 
:  abstract_literal 

I  abstract .literal  /♦  physical.literal  */ 

naune  /*  Identifier  •/  /*  in  LRM:  UNIT.nane  */ 

/*  nane  in  physical.literal  causes  conflict  */ 


/*  7_3_2  */ 
aggregate 
:  '(’ 

element.association 

_ element .association _ 

RightParen.ERR 


element.association 
:  expression 
I  choice 

_ Bar _ choice _ 

Arrow 

expression 
I  simple.expression 

direction  /♦  because  of  production  for  "choice*' 

to  avoid  conflict  ♦/ 

simple.expression 
I  name 

range. constraint 


choices 
:  choice 
_ Bar _ choice _ 

{ 

yyerrok; 
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> 


_ Bar _ choice _ 

:  /*empty*/ 

I  _ Bar _ choice _ 

Beu: 

choice 


choice 

:  simple.expression  /*  includes  simple.naae  */ 

I  simple.expression 
direction 

simple.expression  /*  because  of  production  for  "discrete.range" 
to  avoid  conflict  */ 

I  neune 

range.constraint 
I  OTHERS 


/*  7_3_3  ♦/ 

/♦  function.call 
:  Identifier 
actual_parameter_part 


actual.peurameter.part 


association.list 
Right  Par en.ERR 

;  function.call  handled  by  selected  name  */ 

/*  _actual_parameter_part_ 

I  '(' 

association.list 

RightParen.ERR 

;  *  function.call  handled  by  selected  name  */ 

/♦  7_3_4  */ 
qualif ied.expression 
:  name 
Apostrophe 
aggregate 
/* 

**  type.mark  ’  aggregate  I  type.mark  ’  (  expression  ) 
*/ 
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/*  7_3_5  ♦/ 

f*  type_convArsion  causes  reduce/reduce  conflict 
:  Identifier  type.mark 
' ( '  aggregate 
expression 
RightParen.ERR 


*/ 

/♦  7_3_6  ♦/ 
aJ.locator 

:  HEW 

/♦  8ubtype_indication 

I  HEW  causes  numerous  reduce/reduce  conflicts  */ 
qualified. expression 


/* 

ee  Chapter  8:  Sequential  Statements 

*/ 

/*  8_0  ♦/ 

s equence.of _s tat ement s 

:  _ sequential.statement _ 

I  error  EHD.ERR 

{ 

yyerrok ; 

} 

I  error  ELSIF 

{ 

yyerrok ; 

} 

I  error  ELSE 

■C 

yyerrok ; 

} 

I  error  WHEN 

yyerrok ; 

} 


_ sequential. statement _ 

:  /*empty*/ 

I  sequential.statement 
_ s  equent ial_  statement _ 


143 


s  equent ial.st at  emant 
:  assertion.stateatent 
I  sign2J._a8sigiuent_statement 
I  V2uriable_assigiiment_statemezit 
I  il.statanent 
I  case.stataaant 
I  loop.statanant 
I  naxt_stateaent 
I  exit.statenent 
I  return_8tataBent 
I  null_8tateB6iit 
I  procadtira_call_8tatemeiit 
I  vait_8tatamant 


/♦  8_1  ♦/ 
8ait_8tataBant 
:  WAIT 

_sen8itivity_claii8e_ 
.condition. clau8e_ 

.t imaout .clans a. 
Semicolon.ERR 


.sensitivity. clausa. 
:  /eeBipty*/ 

I  sans it ivity. clause 


.condition.clause. 
:  /eempty*/ 

I  condition.clause 


.timeout. clause. 

/♦empty*/ 

I  timeout. clause 


sensitivity.clause 
:  01 

/♦  sensitivity.list  ♦/ 
signal.list 


condition.clause 
:  UITIL 
expression 


timeout.clause 
:  FOR 

expression 


/* 

**  returns  SYN_REF  op  tree  indexes 
*/ 

signal.list 
:  name 

_ name _ 

I  OTHERS 
I  ALL 


_ name _ 

:  /*empty*/ 
I _ name _ 

>  9 

f 

name 


/♦  8_2  */ 

assertion.statement 
:  ASSERT 
expression 

_REPORT _ expression. 

.SEVERITY _ expres  s ion. 

Semicolon.ERR 


.REPORT _ expression. 

:  /♦empty*/ 

I  REPORT 
expression 


.SEVERITY _ expression. 

;  /eempty*/ 

1  SEVERITY 
expression 


/*  8.3  */ 

s ignal.as  s ignment. statement 


target 


TP_arch  2u:ch_ptr 
TP.entity  ent_ptr 
TP.port  port_ptr 
TP.port  the_port 


arch_get(arch_c_get_id() ) ; 
entity_get(arcli_ptr->najne) ; 
«iit_ptr->port_li8t ; 
port_get ( ident.get ( ) ,  port_ptr) ; 


mcode_add(the_port->number) :  //  Offset  of  the  port 

} 

LESym 

.TRANSPORT. 

{ 

G.translate  =  TRUE;  //  Start  translating  signals  to  offsets 

} 

saveform 

Semicolon.ERR 

{ 

mcode.add(M.POST) ; 

} 


target 
:  name 
I  aggregate 


savefom 

:  waveform.element 
_ waveform.element _ 


_ waveform.element _ 

:  /*empty*/ 

I 

waveform.element 
_ waveform.element _ 


/♦  8.3.1  *! 
waveform.element 

:  expression  /*  HULL  can  be  arrived  at  through  expression  -  literal  */ 
.AFTER _ expression. 


.AFTER _ express ion. 

:  /*empty*/ 

I  AFTER 

expression  /*  numeric.literal  */  /*  in  LRM:  expression  <•>/ 
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/*  8_4  ♦/ 

var  iable.as  s igiunent. statement 
:  target 
VarAsgn 
expression 
Semicolon_ERR 


/*  8_6  ♦/ 

procedure_call_statement 

:  name  name  includes  "name  (  association.list  )“  «/ 
Semicolon.ERR  /e  need  to  include  actual_parameter_part 
-  causes  conflict  */ 


/*  8_6  ♦/ 
if_statement 
;  IF 

condition 

THEI 

sequence.of .statements 

_ ELSIF _ THEN _ seq_of_stmts _ 

.ELSE _ seq. of .stmts. 

EID.ERR 

IF 

Semicolon.ERR 


_ ELSIF _ THEN _ seq.of. stmts _ 

:  /eempty*/ 

I  ELSIF 
condition 
THEN 

sequence.of .statements 
_ ELSIF _ THEN _ seq.of .stmts _ 

{ 

yyerrok ; 

> 


.ELSE _ seq.of .stmt  s. 

:  /eemptye/ 

I  ELSE 

sequence.of .statements 

{ 

yyerrok ; 

} 


/*  8.7  */ 
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case_statement 
:  CASE 
expression 
IS 

cas  e.stat  eaent  _alt  emat  ive 

_ case_statement_altemative _ 

EIO.ERR 

CASE 

Semicolon.ERR 


_ case_statement .alternative _ 

:  / *empty*/ 

I _ case_statement_altemative _ 

case.statenent.alt  emat  ive 

yyerrok; 

> 


case_statenent_alt  emat  ive 
;  WHEH 
choices 
Arrow 

sequence_ol_statements 


/♦  8_8  */ 

/* 

ee  To  avoid  shift/reduce  conflicts,  define  rules  for  labeled/unlabeled  loop 
**  statement 
*/ 

loop.statement 
:  a.label 

unlabeled_loop_statement 
I  unlabeled_loop_statement 


unlabeled_loop_statement 
:  .iteration. scheme. 

LOOP 

sequence.of .statements 

EHD.ERR 

LOOP 

.label. 

Semicolon.ERR 


_ it  er at ion. s  cheme. 
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:  /♦empty*/ 

I  iteration.scheme 


iteration.scheme 
:  WHILE 
condition 
I  FOR 

loop.par ameter .specif ication 


.label. 

:  Z+empty*/ 
I  label 


loop.parameter.specif ication 
:  Identifier 
IH 

di s  cr et  e.range 


/♦  8.9  ♦/ 
next.statement 
:  lEXT 
.label. 

.WHEI _ condition. 

Semicolon.ERR 


.WHEI _ condition. 

:  /*empty*/ 

I  WHEI 
condition 


/*  8.10  ♦/ 
ex it .statement 
:  EXIT 
.label. 

.WHEI _ condit ion. 

Semicolon.ERR 


/*  8.11  ♦/ 
retum.statement 
:  RETURI 
.expression. 
Semicolon.ERR 


.expression. 

:  /*empty*/ 

I  expression 
• 

/*  8.12  ♦/ 
null.statement 
:  BULL. 
Semicolon.ERR 


/♦ 

*  chapter  9  -  concurrent  statements 
*/ 

/*  9.0  ♦/ 

set .of .statements 

:  concurrent. statement 

I  error  EID.ERR 


_ concurrent.statement _ 

:  /*empty*/ 

I  concurrent.statement 
_ concurrent.statement _ 


concurrent.statement 
:  block.statement 
I  process.statement 
{ 

#ifdef  .DBl. 

puts("  !  arch.add.processO") ; 

#endif 

arch.add.processO;  /*  lOTE:  Only  one  process  is  alloued 

} 

I  concurrent.assertion.statement 
I  concurrent. signal.assignment. statement 
I  component. instant iation.statement 
{ 


#ifdef  _DB1. 

puts("  !  arch.add.comp.inst.listO”); 
#endif 

arch.add.comp.inst.listO ; 

} 

I  generate. statement 
I  concurrent.procedure.call 


/*  9_1  ♦/ 

block.statement  needs  changing 

:  a_label 
BLOCK 

_gneu:d_expression_ 

_gener i c_  clans  e_map_anpect  _ 

_poi t_clause_map_aspect_ 
block_decleu:at ive_part 
BEGIK_ 

set_of .statements 

EHD.ERR 

BLOCK 

.label. 

Semicolon.ERR 


.guard. expres  s ion. 
:  /*e!npty*/ 

I  guard.expression 


guard.expression 

: 

expression 

RightParen.ERR 


.generic.clause.map.aspect. 

;  /fempty^/ 

I  generic. clause 
.generic.map.aspect.Semicolon. 

I 

.generic.map.aspect.Semicolon. 

I  generic.map.aspect 
Semicolon.ERR 


.port.clause.map.aspect. 

;  /♦empty*/ 

I  port.clause 

.port.map.aspect .Semicolon. 

* 

.port.map.aspect.Semicolon. 

I  port.map.aspect 
Semicolon.ERR 
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block_declarative_part 
: _ block_declarative_iteni _ 


/♦  9_2  */ 

/♦ 

**  To  avoid  shift/reduce  conflicts,  define  rules  for  labeled/unlabeled  process 
statements. 

*/ 

process.statement 
:  a.label 

unlabeled.process.statement 
I  unlabeled.process.statement 


unlabeled.process.statement 
:  PROCESS 

#ildef  .DBl. 

puts("  !  process. clearO") : 

#endif 

process.clearO ; 

> 

.sensitivity.list. 

process.declarative.part 

BEGIN. 

{ 

process.clearO ; 
mcode.clear.listO ; 

} 

sequence.of .statements 
•t 

//  Place  END  opcode  in  block 
mcode.addCH.ENO) ; 
process.add.mcodeO ; 
new.sim.block(arch_c_get.id()) ; 

add.code_to.sim.block(create_c_sim.process() ,"CORRECT.CODE.TITLE") ; 
create.all.hypoO ; 
f  inish.sim.blockO ; 

} 

END.ERR 

PROCESS 


.label. 

Semicolon.ERR 


.sensitivity.list. 
:  /♦empty*/ 


152 


I  sensitivity.list 


sensitivity_list 

signal.list 

RightParen.ERR 


process_declatrative_part 
:  _ process_declarative_item _ 


_ process_declarativa_iteB _ 

:  /*empty*/ 

I  _ process.daclarative.item. 

process_d«clarative_iteB 

yyerrok ; 

} 


process_declarative_iteB 
:  constant.declaration 
I  variable.declaration 
I  type.declaration 
I  subtype.declaration 
I  attribute.declaration 
I  attribute.specif ication 
I  subprograB.declaration 
I  subprograB_body 
I  f ile.declaration 
I  alias.declaration 
I  use.clause 


/*  9_3  ♦/ 

/* 

**  to  avoid  shilt/reduce  conflicts  for  concurrent_procedure_call 
**  define  rules  for  labeled  and  unlabeled  stateaents  sepeurately 
*/ 

concurrent _procedure_call 
:  a_label 

unlabeled_concurrent_procedure_call 
I  unlabel ed_  concurr ent_pr o  cedur e_  call 


unlabeled_concurrent_procedure_call 
:  procedure.call.stateaent 
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/*  9_4  *! 

/* 

**  To  avoid  shilt/reduce  conflicts,  define  rules  for  labeled/unlabeled 
concurrent .assert ion_8tatenents_ 

** 

**  This  creates  an  equivalent  process  statement  which  has  a  sensitivity 
**  list  of  the  longest  static  prefix  of  each  signal  name  appearing  in 
**  the  boolean  expression  of  the  assertion  statement. 

*/ 

concurrent.assertion.statement 
:  a.label 

unlabeled.concurrent.assertion.statement 
I  unlabeled.concurrent.assertion.statement 


uni abe 1 ed. c oncurr ent . as s ert ion. St at ement 
:  assertion.statement 


/*  9.5  */ 

/* 

**  To  avoid  shift/reduce  conflicts,  define  rules  for  labeled/unlabeled 
concurrent.signal.assignment.statements. 

** 

**  This  creates  an  equivalent  process  statement.  See  8.2.4  of  the  LRM. 
*1 

concurrent. signal.assignment. statement 
:  a.label 

unlabeled.conditional.signal.sissignment 
I  unlabeled.conditional.signal.assignment 
I  a.label 

unlabeled.selected.signal.assignment 
I  unlabeled.selected.signal.assignment 


/*  9.5.1  */ 

unlabeled. conditional. signal.assignment 
:  target 
LESym 

/♦  options  */ 

.GUARDED. 

.TRAMSPORT. 

/♦  conditionzd.waveforms  */ 

_ wavef  orm _ VHEH _ condit ion _ ELSE _ 

waveform 

Semicolon.ERR 
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_ savel  onn _ WHEN _ condit  ion _ ELSE _ 

:  /♦empty*/ 

I  _ naveform _ WHEN _ condition _ ELSE _ 

waveform 

WHEN 

expression 

ELSE 


/*  9_5_2  */ 

iinlabeled_selected_signal_assignment 
:  WITH 
expression 
SELECT 
target 
LESym 

/*  options  ♦/ 

.GUARDED. 

.TRANSPORT. 

/♦  selected.waveforms  ♦/ 

waveform 

WHEN 

choices 

_ waveform _ WHEN _ choices _  /*  changed  from  LRM  for  consistancy  */ 

Semicolon.ERR 


_ waveform _ WHEN _ choices _ 

:  /eempty*/ 

I  _ waveform _ WHEN _ choices _ 

i  f 
» 

waveform 

WHEN 

choices 


.GUARDED. 

:  /eempty*/ 
I  GUARDED 


.TRANSPORT. 
;  /♦ empty*/ 
I  TRANSPORT 
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/*  9_6  */ 

compoaent _ instant iat ion_ St at ement 
:  a.label 
/*  Identifier  */ 
name 

{ 

conp_inst_list_add_node(ident_save_get() ) ; 
comp_inst_entit j ( ident_get ( ) ) ; 

> 

_generic_map_aspect_ 

{ 

portmap_list_clear() ; 

> 

_port_Bap_ aspect. 

comp. inst.portmap (portmap.get ( ) ) ; 

> 

Semicolon.ERR 


.port.map.aspect. 

:  /*empty*/ 

I  port.map.aspect 

I 

port.map.aspect 

PORT 

MAP 

assoc.list.clearO ; 

} 

’  ( ’  /♦  eas :  PORT  aggregate  ♦/ 

association.list 

{ 

portmap.list.add.nodeC  assoc.list.getO  ); 

} 

RightParen.ERR 


.generic.map.aspect. 
:  /♦empty*/ 

I  generic.map.aspect 
> 

generic.map.aspect 

GEMERIC 

MAP 
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association.list 

RightParen.ERR 


/*  9_7  *! 

/* 

**  To  avoid  ahilt/reduce  conflicts,  define  labeled/nnlabeled  generate 
**  stateaents. 

*/ 

generate.statenent 
:  a_label 

unlabeled_generate_statement 
/*  I  unlabeled_generate_statement 
*/  : 

nnlabeled.generate.statement 
:  generation_scheme 
6EIERATE 

set _Qf .statements 
EHD.ERR 
GEIERATE 
.label. 

Semicolon.ERR 


generat ion.s  cheme 
:  FOR 

generat  e.paramet er .spec if i cat ion 
1  IF 

condition 


generat  e.paramet  er _  spec if i cat ion 
:  Identifier 
IH 

discrete.range 


condition 
:  expression 


/* 

**  label  declaration 
*/ 

a.label 
:  label 

>  .  f 

ident.saveO ;  Save  ident;  case  of  2  idents  before  parsed  */ 

> 
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label 

:  Identifier 


/* 

**  Chapter  10:  Scope  and  Visibility 
*/ 

/*  10_4  */ 
use_clause 
:  USE 

selected.naae  !*  package  sinple  name 

_ selected.name _ 

Semi colon_ERR 


_ selected_name _ 

:  /eempty*/ 

I  _ selected_name _ 

I  > 

9 

select ed.name 

} 

/* 

■"e  Design  Units  and  Their  Analysis 
*/ 

/*  11_1  ♦/ 
design.f ile 
:  design.nnit 
_ design.unit _ 


_ design.unit _ 

:  /♦empty*/ 

I  design.unit 
_ design.unit _ 


design.unit 
:  context. clause 
library.unit 


library.unit 
:  primary.unit 
I  secondary .unit 


I  error 


primary  _\mit 
:  entity_declaration 
I  coni  iguration.declairat  ion 
I  package.declaration 


secondary.unit 
:  architecture.body 
I  package.body 


/♦  Design  Libraries  ♦/ 
/*  11_2  ♦/ 

library_clause 
:  LIBRARY 
logical.name.list 
Semicolon.ERR 


logical_name_list 
;  Identifier 
_ logical.name _ 


_ logical.name _ 

:  /*empty*/ 

I _ logical.name _ 

t  t 
» 

Identifier 


/*  11_3  ♦/ 
context .clause 
: _ context.item.. 


_ context.item _ 

:  /’•■empty*/ 

I  _ context.item _ 

context.item 


context.item 
:  libreury. clause 
I  use.clause 
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/*  A_4  ♦/ 

/♦  abstract.literal  ♦/ 

/♦ 

**  Normally,  the  grammar  lor  abstract  literal  mould  be  found  here.  It 
**  has  been  moved  to  the  end  of  this  file.  There  you  mill  find  an 
**  explanation. 

*/ 

Error  recovery  non-terminals 

ee 

/* 

*  Make  and  ’end’  significant  for  error  recovery. 

*/ 

RightParen.ERR 
:  ’)’ 

{ 

yyerrok ; 

> 


Semicolon.ERR 

•  >  .  I 

•  I 

{ 

yyerrok; 

} 


EMD.ERR 
:  EHD. 
{ 

yyerrok; 

} 


/* 

**  In  order  to  implement  floating  point  notation,  it  mas  necessary  to 
**  decleure  the  types  of  the  parameters  for  ’ abstract .literal.real’  and 
**  ’abstract.literal.int’ ,  as  mell  as  the  return  type  for  ’abstract. literal’ 
**  But  if  you  do  this,  then  yacc  demands  that  all  folloming  grammar  rules 
**  be  similarily  typed.  Therefore,  this  special  case  mas  made  the  last 
rule  in  the  grammair.  This  mill  cause  the  compiler  to  complain  about 
"struct/union  or  struct/union  pointer  required",  but  the  source  code 
**  produced  by  yacc  is  correct. 

*/ 

abstract.literal 
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:  Decimallnt  {/♦puts(" - !  found  decimal  int");*/} 

I  DecimalReal  {puts(" - !  found  decimal  real");} 

I  Basedint  {puts(" - !  found  based  int");} 

I  BasedReal  {puts(" - !  found  based  real"):)’ 

%•/. 

int  yyeiTor(char  *s) 

{ 

printf  ( "YYError :  ’/.s\n" ,  s ) ; 

> 
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D.3  UV.LEX 


U 

/* 


UV.LEX 

This  file  contains  the  FLEX  code  for  recognizing  the  VHDL  tokens 

*/ 

#include  <stdio.h> 

#include  <conio.h> 

#include  <string.h> 

#include  <io.h> 

#include  "ident.h" 

#inclnde  “thesis. h" 

#include  "uv_tab.h" 

#include  <alloc.h> 

char  *strip_underscore() ; 
extern  char  YACC.STR.LITD : 
extern  FILE  ♦infile ; 

#nndef  YY.IHPUT 

#define  YY_IHPUT(buf .result .max.size)  \ 

i  \ 

int  c  =  getcCinf ile) ;  \ 

result  =  (c==EOF)  ?  YY_HULL  ;  (buf[0]=c,l);  \ 

> 

•/.} 

A  [eUl] 

B  [bB] 

C  CcC] 

D  [dD] 

E  [eE] 

F  CfF] 

G  [gG] 

H  [hH] 

I  Cil] 

J  tjJ] 

K  [kK] 

L  CIL] 

M  [mM] 

H  CnR] 

0  [oO] 

P  CpP] 

q  CqQ] 

R  CrR] 

S  [sS] 

T  [tT] 
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U  [uU] 

V  [vV] 

V  CvV] 

X  [xX] 

V  [yY] 

Z  [zZ] 

digit  [0-9] [0-9_] ♦ 

intlit  {digit} 
integer  {intlit} 
string  ["]  (  C-\n\t"3  I  (\*'\")  )♦  C"3 
comment  — ["Xn]* 
ws  [  \t] + 

nl  \n 

varasgn 
doublestar 
lesym 
gesym 
nesym 
arros 

•/.*/. 

{us}  ; 

{comment}  {if (is_flag_set(PRIIT_COMM))  puts(yytext) ;} 

putsC'SOMETHIIG  IS  ROIG") ; 
return  Apostrophe; 

} 

{doublestar}  { 

return  DoubleStar; 

} 

{varasgn}  { 

return  VarAsgn; 

} 

{lesym}  { 

return  LESym; 

} 

{B}{I}{T}  { 
return  BIT; 

} 

{B}{0}{X}  { 
return  Box; 

} 

{arrow}  { 

return  Arrow; 

} 

{gesym}  { 

return  GESym; 

} 


[*]  [♦] 
C<]  C=] 
>= 

\\= 
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{B}{A}{R>  { 
return  Bar; 

} 

{nesym}  { 

return  KESym; 

} 

{S>{L>{A}-CS}<H>  { 
return  Slash; 

} 

{lKdigit}{digitKdigit}  { 

/•printf  ( "Lexxed  I  '/,s  I  \n" ,  yytext)  ;  ♦/ 

ident_set(yytext) ; 

return  Identifier; 

> 

■Cintlit}  { 

lit_set(yytext) ; 
return  Decimalint; 

} 

{R>{E>{A}{L}  { 

return  DecimalReal ; 

> 

{B>{A}{S}{E}{D>{I>{I}m  { 
return  Basedint; 

} 

{B>{A}{S}{E}{D>{R>{E}{A}{L>  { 
return  BasedReal; 

} 

{C>{H>{A}{R}{A>{C}m-CE}{R}{L>{I}m  { 
return  ChsuracterLit; 

> 

{S>{T}{R}{I}{H>tG}{L}{I}m  { 
return  StringLit; 

} 

{B>{i}m-cs}{T>{R}{i}a}{G>{L>{i}m  c 

return  BitStringLit; 

} 

{A}{B}{S}  { 
return  ABS; 

} 

{A}{C}{C}{E}{S}{S>  ■[ 
return  ACCESS; 

} 

{A>{F}{T}{E}{R}  { 
return  AFTER; 

} 

{A>a>{I>{A}{S>  { 
return  ALIAS; 

} 

{A}{L}{L}  { 
return  ALL; 

} 


•[A}{I}{D}  { 
return  AND; 

} 

{A}{R>{C}{H}{I}m{E}{C}{T>{U>-CR}<E}  { 
return  ARCHITECTURE; 

} 

{A>{R>{R}{A>{Y}  { 
return  A?JIAY; 

} 

{AHSHSHEHRHT}  < 
return  ASSERT; 

} 

{A>mm-CR>{I}{B}{U}{T}-CE>  { 
return  ATTRIBUTE; 

} 

{B>-CE>{G}{I>{N}  { 
return  BEGIN.; 

> 

{B}{L>{0}-[C}{K>  { 
return  BLOCK; 

} 

{B>{0}{D>{Y}  { 
return  BODY; 

} 

■CB}{U}{F}{F}<E}{R}  < 
return  BUFFER; 

{B}{U}{S}  { 
return  BUS; 

> 

•CC}{A>{S}{E}  { 
return  CASE; 

} 

•CC}{0>{M}{P}-[0}{H>{E}{N}m  { 
return  COMPONENT; 

} 

•CC}{OHN}-(F}{I}{G}{U}{RKAHT}{I}{OKN>  { 
return  CONFIGURATION; 

} 

{C}{0>{N}-CS}{T}{A>{N>{T}  { 
return  CONSTANT; 

} 

{D}{I>{S}{C}{0HH>{N}{E}{CKT}  { 
return  DISCONNECT; 

} 

{D}{0>m{N>m{0}  i 

return  DOWNTO; 

} 

{E}{L>{S}{E}  { 
return  ELSE; 

} 
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{E}{L}{S}{I}-[F}  { 
return  ELSIF; 

} 

{E}{H}{D}  < 
return  EID_; 

} 

{E}{H>{T>{I}{T}m  { 
return  EITITY; 

> 

{E}{x>{i}m  { 

return  EXIT; 

} 

{F}{I>{L}{E}  { 
return  FILE_; 

} 

{F}{0}{R}  { 
return  FOR; 

> 

{F}m{H}{C}{T}tI}{0}{H}  { 
return  FUNCTION; 

} 

{G}{E}{N}-(E}{R}{A}{T}{E}  i 
return  GENERATE; 

} 

<GHE>{N>{E>{R}{I}{C}  { 
return  GENERIC; 

} 

{G}{U>{A}{R}{D}{E}{D>  -C 
return  GUARDED; 

} 

•CIKF}  -C 

return  IF; 

> 

{I}{N}{0}mm  { 

return  INOUT; 

} 

{IHN}  { 

return  IN ; 

} 

<I}{S}  { 

return  IS; 

} 

{L>{A}{B}{E}{L}  { 
return  LABEL; 

> 

{L}{I}{B}{R}-(A}{R}{Y}  { 
return  LIBRARY ; 

> 

{L}{I}{N}{K}{A}{G>{E}  { 
return  LINKAGE; 

> 


{L}{0}{0>{P}  { 
return  LOOP; 

> 

{M}-CA}{P>  -C 
return  MAP; 

} 

{M}<0>tD}  { 
return  NOD; 

} 

{H}{A>tH>{D}  { 
return  NAHD; 

} 

{N}{E>-CW}  i 
return  NEW; 

} 

{H}{E}{X}{T>  { 
return  NEXT; 

} 

{N}{0}{R>  { 
return  NOR; 

} 

{N}{0}{T>  i 
return  NOT; 

} 

{N}{U}{L>{L}  { 
return  NULL_; 

} 

{0}{F}  { 

return  OF; 

> 

■(0}{N}  { 

return  ON; 

} 

{0}{P}{E>{N>  { 
return  OPEN; 

} 

{0}{R}  { 

return  OR; 

} 

{0}{T}iN>{E>{R}-CS}  { 
return  OTHERS; 

} 

{0>{U}{T}  { 
return  OUT; 

} 

{P}{A}{C}{K}{A}{G}{E}  { 
return  PACKAGE; 

} 

{P}-(0>{R}{T>  { 
return  PORT; 

> 


{P}{R}{0}{C}{E}{D}m{R}{E}  { 
rettim  PROCEDURE; 

> 

{P>{R}{0}{C}{E}{S}{S}  { 
return  PROCESS; 

} 

{R}{A}{*}{G>{E}  { 
return  RAH6E; 

> 

{R}-[E>{C>{0}{R}{D}  { 
return  RECORD; 

> 

{R}{E}{G}{I>{S}m{E}{R}  { 
return  REGISTER; 

} 

{R}{E}{M}  i 
return  REM; 

} 

{R}{E}{P}{0>{R}{T}  { 
return  REPORT; 

} 

{R}{E}m{U}{R}{H}  { 
return  RETURN; 

} 

{S}{E}a}{E}{C}{T}  i 
return  SELECT ; 

} 

{S}<E}{V}{E}{R}{I}{T}m  -C 
return  SEVERITY; 

} 

{S}{I}{G}{N}{A}{L}  < 
return  SIGNAL; 

} 

{S}m{B}m{Y}{PME}  {. 
return  SUBTYPE; 

} 

{T}{H}{E}{N}  ■[ 
return  THEN; 

} 

{T>-[0}  { 

return  TO; 

} 

{T}-CR}{A}{N}-CS}{P}{0}m{T}  { 
return  TRANSPORT; 

} 

{T>{Y}{P}{E}  { 
return  TYPE; 

} 

m{N){i}m{s}  { 

return  UNITS; 

} 


<u>{i}m{i>{L}  { 

return  UNTIL; 

> 

m{S>{E>  { 
return  USE; 

} 

W{A}{E}{I}{A}{B>{L}{E>  { 
return  VARIABLE; 

} 

{W>{A}{I}m  { 
return  WAIT; 

> 

m{H}{E}{I>  { 
return  WHEN; 

} 

m{H>{I>{L>{E}  { 
return  WHILE; 

} 

m{I}{T}{H>  { 
return  WITH; 

} 

{X>{0}{R}  { 
return  XOR; 

} 

{U}{N}{A}{R>{Y}{S}{I}<G}<N}  { 
return  UNARY.SIGN; 

} 

■cm}  { 

/*  extern  int  lineno;  ♦/ 

/*  lineno•*■•^;*/ 

/♦puts ("End  of  Line."):*/ 

} 


return  yytextCO] ; 


Appendix  E.  Parser  Source  Code 


E.l  Overview 

These  modules  are  tightly  linked  to  the  UV  module  described  in  Appendix  A.l.  As  soon  as 
a  VHDL  construct  has  been  parsed,  the  associated  code  in  the  UV  module  calls  the  routines  in 
one  of  the  following  modules.  VHDL  constructs  that  consist  of  other  VHDL  objects  reference  the 
routines  of  the  sub-object’s  module. 

All  routines  for  the  parsed  object  are  in  a  separate  module.  In  general,  each  module  has  an 
init  function,  functions  to  set  the  values  of  the  object,  and  a  function  to  return  the  object.  In 
addition,  there  are  also  functions  to  print  the  object’s  value  to  the  screen. 


E.2  ARCH.H 
/• 

VHDL  PARSER 
File:  ARCH.H 
Date:  7  July  1992 

This  module  handles  the  creation  of  an  ARCHITECTURE  by  the 
VHDL  puser.  These  routines  are  called  by  the  BISDH  program. 

Routines : 


arch_clear()  —  Clear  current  arch  settings 
arch_id{)  —  Add  current  identitier  to  arch 
arch_name()  —  Add  current  ident  as  arch  name 

arch_add_signal_list()  —  Add  current  signal  list  to  current  arch 
arch_print(  ent)  —  Print  specified  architectxire 

*/ 

/* - */ 

tifndef  _ arch_h _ 

#define  _ arch_h _  1 

#ifndef  ident _h 

finclude  "ident. h" 
fendif 

fifndef  _ signal.h _ 
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#inclade  "signal. h" 
#endif 

#ifndei  _ comp_h _ 

#include  "comp.h" 
#endif 

#iindel  _ comp_in_h _ 

#include  "comp_in.h" 
#endif 

#ifndel  _ process.h _ 

#include  "process. h" 


#endif 

/* - - - */ 

typedel  struct  S_arch  { 

T_ident  id;  /*  Instance  of  Arch  */ 

T_ident  name;  /♦  entity  for  arch  ♦/ 

TP_signal  signal.list;  /♦  List  of  local  signals  */ 

TP_comp  comp.list;  /*  List  of  local  comp  declarations  */ 

TP_comp_inst  comp_inst_list ;  /*  List  of  comp  instantiations  ♦/ 

T.process  process;  /f  the  ORE  process  in  the  architecture  */ 


struct  S_arch  ♦next; 

}  T.arch; 

/♦  arch  node  pointer  ♦/ 
typedef  T_arch  ♦  TP_arch; 

- ♦/ 

/♦  prototypes  ♦/ 
void  arch_clear(void) ; 
void  arch_add(void) ; 
void  arch_name(void) ; 
void  arch_add_signal_list(void) ; 
void  arch_add_comp_list(void) ; 
void  arch_add_comp_in8t_list(void) ; 
void  arch_add_process(void) ; 
void  arch_c_list_print(void) ; 
void  arch_list_print(TP_arch  list); 
void  arch_print (TP_arch  list); 
int  arch_c_get_id(void) ; 

TP_arch  arch_get(int  id); 


♦/ 


/* - 

# end if 


E.3  ARCH.CPP 

/* 

VHDL  PARSER 
File:  ARCH.C 
Date:  7  July  1992 

This  module  handles  the  creation  of  an  ARCHITECTURE  by  the 
VHDL  parser.  These  routines  are  called  by  the  BISOH  program. 

*/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <assert.h> 

#include  <malloc.h> 

#include  <string.h> 

#include  "thesis.h" 

•include  "eirch.h" 

/* - 

/♦  Current  arch  being  created  */ 

static  TP.arch  current_arch_list: 

/♦ - 

void  arch_clear(void) 

■C 

current_arch_list  =  MULL; 

} 

void  arch_add(void) 

■C 

TP_arch  nev.node; 

if(  (ne«_node  =  (TP_arch)(malloc(sizeof(T_arch))))  ==  MULL  )  { 
yyerrorC'Out  of  memory  in  ARCH_ADD()"); 
exit (129) ; 

> 

new_node->id  = 

new_node->signal_list  = 

new_node->comp_list  = 

neB_node->comp_inst_list  = 
new  node->process  = 

new_node->next  = 

current_arch_list  = 

> 

//  Add  name  to  architecture 
void  arch_name(void) 
i 


ident_get() ; 

MULL; 

MULL; 

MULL; 

MULL.PROCESS; 
current _arch_list ; 
new.node ; 


current_arch_list->name  =  ident_get(); 


} 


void  arch_add_signal_list(void) 

current_arch_list->signal_list  =  signal_get(); 

> 

void  arch_add_comp_list(void) 

{ 

current_arch_list->comp_list  =  conip_get(); 

} 

void  arch_add_comp_inst_list(void) 

current_arch_list->comp_inst_list  =  comp_inst_list_get() ; 

> 

void  arch_add_process(void) 

•C 

current_arch_list->process  =  process_get() ; 

> 

int  arch_c_get_id(void) 

{ 

return  current _arch_list->id: 

} 

void  arch_c_list .print (void) 

{ 

arch_print(current_arch_list) ; 

} 

void  arch.list .print (TP.arch  list) 

if (list  ==  lULL)  { 

putsC'Empty  arch  signal  list"); 

} 

else  •( 

whiledist  !=  HULL  )  { 
arch.pr int (list) ; 
list  =  list->next; 

} 

} 

} 

void  arch.pr int (TP.arch  node) 

{ 

if  (node  ==  HULL)  {. 

puts ("Empty  arch  signal  node"); 

} 

else  { 
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printlC'Arch  id:  "): 
ident_print(  A(node->id)  ); 
print! ("  Maine :  "); 
ident_print(  t(node->naine)  ); 

puts(""); 

putsC'Arch  signal  list"): 
signal_print(  node->signal_list) ; 
putsC'Arch  comp  list"); 
comp_print(  node->comp_list) ; 
putsC'Arch  component  instantiation  list"); 
comp_inst_list_print(  node->comp_inst_list) ; 
putsC'Arch  process"); 
process_print(  *(node->process)  ); 

} 

> 

//  Return  pointer  to  arch  specified  by  ID 
//  Return  MULL  if  not  found 
TP_arch  arch_get(int  id) 

{ 

TP.arch  ptr  =  current _arch_list; 
vhileCptr  !=  MULL  AA  ptr->id  !=  id)  { 
ptr  =  ptr->next; 

} 

assert (ptr  !=  HULL); 
return  ptr; 

} 

/♦ - 
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E.4  ASSOC. H 

/* 

VHDL  PARSER 
File:  ASSOC. I 
Date:  9  July  1992 

This  module  handles  the  creation  of  a  assoc ’s  list  of 
input/output  signals.  Theses  functions  are  called  by  the  BISOI 
program. 

Routines: 


assoc_clear(} 

assoc_add_id() 

assoc_add_id_list() 

assoc.printdist) 


assoc_get() 

*/ 

/* - 


—  Clear  current  assoc  list 

—  Add  current  ident  to  current  assoc  list  ! ! !  MOT  USED 

—  Add  current  ident_list  to  current  assoc  list 

—  Print  supplied  assoc  list.  If  CURREHT_LIST, 
print  out  the  current  list. 

—  Get  pointer  to  current  list. 


*/ 


#ifndef  _ assoc.h _ 

tdefine  _ assoc.h _  1 


#ifndef  _ ident_h _ 

#include  "ident. h" 
#endif 


/♦  assoc  signal  node  */ 
typedef  struct  S.assoc  { 

T_ident  left; 

T_ ident  right; 

struct  S_assoc  *nezt; 

}  T_assoc; 

/♦  assoc  signal  node  pointer  */ 
typedef  T_ assoc  *  TP_assoc; 

/♦ - ,/ 

/*  prototypes  */ 

void  as8oc_list_cloar(void) ; 

void  assoc_list_free(TP_assoc  list); 

void  assoc_list_add_node(void) ; 

void  assoc_leit(T_ident  left); 

void  assoc_right(T_ident  right); 

void  assoc_list_print(TP_assoc  list) ; 

TP_assoc  assoc_list_get(void) ; 

/* - ♦/ 
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#endif 


E.5  ASSOC. CPP 


/* 

VHDL  PARSER 
File:  ASSOC. C 
Date:  9  July  1992 

This  module  handles  the  creation  of  a  assoc 's  list  of 
input/output  signals.  Theses  functions  are  called  by  the  BISOI 
program . 


*/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <malloc.h> 

#include  "thesis. h" 

#include  "assoc. h" 

#include  "misc.h" 

/* - 

/♦  Storage  for  current  assoc  signal  list  ♦/ 

static  TP.assoc  assoc_signal_list  =  HULL; 

/* - 

void  assoc_list_clear(void) 

•C 

assoc_signal_list  =  HULL; 

} 

void  assoc_list_free(TP_assoc  list) 

TP_assoc  ptr; 

if (list  ==  CURREHT.LIST)  { 
list  =  assoc_signal_list; 

} 

whiledist  !=  HULL)  { 
ptr  =  list->next; 
free(list) ; 
list  =  ptr; 

> 

} 

void  as8oc_list_add_node(void) 

i 

TP_assoc  neH_node; 

if(  (neu.node  =  (TP_assoc) (malloc(sizeof (T_assoc))))  ==  HULL  )  { 
yyerrorC'Out  of  memory  in  assoc_ADD_ID()") ; 


exit(lOl) ; 


> 

new_node->left 

new_node->right 

new_node->next 

assoc_signal_list 

} 


-1; 

-1: 

assoc_signal_list; 
nes.node ; 


void  assoc_left(T_ident  left) 

{ 

assoc_signcd_list->left  =  left; 

> 


void  assoc_right(T_ident  right) 

assoc_signal_list->right  =  right; 

} 


void  assoc_list_print(TP_assoc  list) 

if (list  ==  HULL)  { 

putsC'Empty  association  list"); 

} 

else  { 

if (list  ==  CURRENT.LIST  )  { 

putsC'Found  CL;  printing  current  list:") 
list  =  assoc_signal_list; 

> 

shiledist  !=  NULL  )  { 
printfC'/.d  =>  '/id\n", 

list->lef t ,list->right) ; 
list  =  list->next; 

} 

} 

} 

TP_assoc  assoc_list_get(void) 
return  assoc_signal_list; 

} 

/♦ - 
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E.6  COMP.H 


VHDL  PARSER 
File:  COMP.H 


Date:  9  July  1992 


This  module  handles  the  identifiers  encountered  by  BISOI. 
Routines: 


comp_clear 0 
comp_add_id() 
comp_add_id_list ( ) 
comp_print() 
coiBp_get() 

*/ 

/♦ - 

#ifndef  _ comp_h _ 

#define  _ comp_h _  1 


-  Clear  current  comp 

-  Add  ident  to  comp  ! ! !not  used 

-  Add  current  ident  list  to  current  comp 

-  Print  comp  data 

-  Get  current  comp  data 


*/ 


#ilndef  ident _h 

#include  " ident. h" 
#endif 


#ifndef  _ port_h _ 

#include  "port.h" 
#endif 


/*  comp  signal  node  ♦/ 
typedef  struct  S_comp  { 

T_ident  id; 

TP_port  port ; 

struct  S_comp  *next;' 

}•  T_comp; 

/♦  comp  signal  node  pointer  */ 
typedef  T_comp  *  TP_comp; 

/* - */ 

/*  prototypes  */ 
void  comp_clear_list(void) ; 
void  comp_add_comp(void) ; 
void  comp_add_port(void) ; 
void  comp_print (TP_comp  list); 

TP_comp  comp_get(void) ; 

TP_comp  comp_get(int  name,  TP_comp  ptr) ; 

/♦ - */ 
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tendil 


180 


E.7  COMP.CPP 


/* 

VHDL  PARSER 
File:  COMP.C 
Date:  2  July  1992 

This  module  handles  the  creation  oi  a  comp’s  list  of 
input/output  signals.  Theses  functions  are  called  by  the  BISOH 
program. 


*/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <malloc.h> 

#include  "thesis. h" 

#include  "comp.h" 

#include  "misc.h" 

/* - ♦/ 

/*  Storage  for  current  comp  signal  list  */ 

static  TP.comp  comp_list  =  lULL; 

/•  Storage  for  current  comp  */ 
static  T_comp  current.comp; 

/* - */ 

void  comp_clear_list(void) 

{ 

comp.list  =  lULL; 

> 

void  comp_add_comp(void) 

TP_comp  new_node; 

if(  (neu.node  =  (TP_comp)(malloc(sizeof(T_comp))))  ==  HULL  )  { 
yyerrorC'Out  of  memory  in  comp_ADD_ID()") ; 
exit(102) ; 

} 

new_node->id  =  ident_get(); 

new_node->next  =  comp.list; 

comp_list  =  new.node; 

} 

void  comp_add_port (void) 

{ 

comp_list->port  =  port_get(); 

} 
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void  coBp_print (TP_comp  list) 

i 

if (list  ==  HULL)  { 

putsC'Empty  comp  signal  list"): 

} 

else  { 

if (list  ==  CURREMT_LIST  )  { 

putsC'Foimd  CL;  printing  current  list:"); 
list  =  comp_list; 

> 

while (list  !=  HULL  )  { 
printf ("Hame:  ") ; 
ident_print(  h(list->id)  ); 
putsC'"); 

printf ("Port  list:\n"): 
port_print(  (list->port)  ); 
list  =  list->next: 

> 

> 

> 

TP_comp  comp_get(void) 

{ 

return  comp.list; 

} 

//  Return  pointer  to  entity  specified  by  ID 

//  Return  HULL  if  not  found 

TP_comp  comp_get(int  id,  TP_comp  ptr) 

{ 

while(ptr  !=  HULL  tt  ptr->id  !=  id)  { 
ptr  =  ptr->next; 

> 

return  ptr; 

} 


E.8  COMP. IN.  H 


/* 

VHDL  PARSER 
File:  COMP_IH.H 
Date:  9  July  1992 

This  module  handles  the  creation  of  a  comp.inst’s  list  of 
input/output  signals.  Theses  functions  are  called  by  the  BISOI 
program. 

Routines: 


comp_inst_clear()  —  Clear  current  comp_inst  list 

comp_inst_add_id()  —  Add  current  ident  to  current  comp_inst  list 

comp_inst_add_id_list()  —  Add  current  ident_list  to  current  comp_inst  list 
comp_inst_print(list)  —  Print  supplied  comp_inst  list.  If  CURREMT_LIST , 

print  out  the  current  list . 

comp_inst_get()  —  Get  pointer  to  current  list. 

*/ 

/♦ - ♦/ 

#ifndef  _ comp_in_h _ 

#define  _ comp_in_h _  1 

#ifndef  _ ident.h _ 

tinclude  '* ident. h" 

#endif 

#ifndef  _ portmap_h _ 

#include  "portmap.h" 

#endif 


/*  comp_inst  signal  node  ♦/ 
typedef  struct  S_comp_inst  { 

T_ ident  name; 

T_ident  entity; 

TP_portmap  portmap; 

struct  S_comp_in8t  *next; 

}  T_comp_inst; 

/*  comp.inst  signal  node  pointer  */ 
typedef  T_comp_inst  TP_coinp_inst; 

/♦ - ♦/ 

/*  prototypes  ♦/ 

void  comp_in8t_list_clear(void) ; 

void  comp_inst_list_free(TP_comp_inst  list) ; 

void  comp_in8t_list_add_node(T_ident  name); 
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void  comp_inst_entity(T_ident  entity) ; 
void  coinp_inst_portmap(TP_portinap  portmap); 
void  comp_inst_list_print(TP_comp_inst  list); 
TP_coinp_inst  comp_inst_list_get(void) ; 

TP_coBip_inst  comp_inst_get(int  id,  TP_coinp_inst  ptr); 


/♦ - 

#endif 


E.9  COMPJN.CPP 


/* 

VHDL  PARSER 
File:  COMP_IH.C 
Date:  9  July  1992 

This  module  handles  the  creation  of  a  comp_inst’s  list  of 
input/output  signals.  Theses  functions  are  ceLLled  by  the  BISOH 
program . 


*/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <malloc.h> 

#include  "thesis. h" 

# include  "comp_in.h" 

#include  "misc.h" 

/* - */ 

/*  Storage  for  current  comp.inst  signal  list  */ 

static  TP_comp_inst  comp_inst_list  =  HULL; 

/* - */ 

void  comp_inst_list_clear(void) 

{ 

comp_inst_list  =  HULL; 

} 

void  comp_inst_list_free(TP_comp_inst  list) 

TP_comp_inst  ptr; 

if (list  ==  CURRENT.LIST)  { 
list  =  comp_inst_list ; 

} 

whiledist  !=  HULL)  { 
ptr  =  list->next; 
free(list) ; 
list  =  ptr; 

} 

} 

void  comp_inst_list_add_node(T_ident  name) 

TP_comp_inst  new.node; 

if(  (neH_node  =  (TP_comp_inst)(malloc(sizeof (T_comp_inst))))  ==  HULL  )  { 
yyerrorC'Out  of  memory  in  comp_in8t_ADD_ID()") ; 
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exit (103) ; 


} 

new_node->iiaine  =  name ; 
new_node->next  =  comp_inst_list ; 
comp_inst_list  =  neu.node; 

} 

void  comp..inst_entity(T_ident  entity) 

{ 

comp_inst_list->entity  =  entity; 

> 


void  comp_inst_portmap(TP_portmap  portmap) 

{ 

comp_inst_list->portmap  =  portmap; 

} 

void  comp_inst_list_print(TP_comp_inst  list) 

■C 

if (list  ==  NULL)  { 

putsC'Empty  comp_instiation  list*'); 

} 

else  { 

if (list  ==  CURREHT.LIST  )  { 

puts ("Found  CL;  printing  current  component  list:"); 
list  =  comp_inst_list; 

} 

Hhiledist  !=  NULL  )  { 

printf ("Name:  y,2d  Entity:  5i2d\n", 
list->name,list”>«ntity) ; 
puts ("Port  map  list:"); 
portmap_list_print(list->portmap) ; 
list  =  list->next; 

} 

> 

> 

TP_comp_inst  comp_inst_list_get(void) 
return  comp_inst_list; 

} 

/* - ♦/ 

//  Return  pointer  to  comp.inst  specified  by  name  in  supplied  comp.inst  list 
//  Return  NULL  if  not  found 

TP_comp_inst  comp_inst_get(int  name,  TP_comp_inst  ptr) 

«hile(ptr  !=  NULL  kk  ptr->name  \=  name)  { 
ptr  =  ptr->next; 

} 

return  ptr; 
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} 

/♦ 
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E.IO  MISC.CPP 


VHD^  PARSER 
File:  MISC.C 
Date:  2  July  1992 

Miscellaneous  routines  lor  functions  called  Iron  BISON 


*/ 

#include  "thesis. h" 

#include  "nisc.h" 

/* - */ 

/*  Storage  for  current  values 

static  int  current_port_direction; 
static  int  current _type_mark ; 

/* - */ 

/♦  Routines  for  handling  current  port  signal  direction  */ 

void  direct_set(int  neu_dir) 

ctirrent  .port  .direction  =  new.dir; 

} 

int  direct_get() 

{ 

return  current .port .direction; 

> 

/* - •/ 

/*  Routines  for  handling  current  type  mark  */ 

void  type.setCint  new.type) 

{ 

current .type.nark  =  new.type; 

} 

int  type_get() 

return  current.type.mark; 

} 

- ♦/ 
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E.ll  ENTITY. H 

/* 

VHDL  PARSER 
File:  EHTITY.H 
Date:  2  July  1992 

This  module  handles  the  creation  of  an  EITITY  by  the 

VHDL  parser.  These  routines  are  called  by  the  BISOI  program. 

Rout ines: 


entity_clear()  —  Clear  current  entity  settings 
entity. id ()  —  Add  current  identitier  to  entity 

entity_add_port()  -  Add  current  port  list  to  entity 

entity.printO  -  Print  out  specified  entity  -  MULL  prints 
out  current  entity 

*/ 

/* - ♦/ 


#ifndef  _ entity.h _ 

#define  entity _h 1 

#ifndef  _ ident.h _ 

#include  "ident.h" 

# end if 

#ifndef  _ port.h _ 

#include  "port.h" 


#endif 

/* - */ 

typedef  struct  S.entity  { 

T.ident  id; 

TP.port  port.list; 


struct  S.entity  *next; 

}  T.entity; 

/♦  Entity  node  pointer  */ 
typedef  T_ entity  ♦  TP.entity; 

!„ - ♦/ 

/*  prototypes  */ 

void  entity_list_clear(void) ; 

void  entity_add(void) ; 

void  entity_add_port(void) ; 

void  entity_c_li8t_print(void) ; 

void  entity_list_print(TP_entity  list); 

void  entity_print(TP_ entity  list); 
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TP_«ntity  entity_get(int  id); 

/♦ - 

#endif 
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E.J2  ENTITY.  CPP 


VHDL  PARSER 
F:'  EHTITY.C 
Date:  2  July  1992 

This  module  handles  the  creation  of  an  ERTITY  by  the 

VHDL  parser.  Thes'^  routines  are  called  by  the  BISOI  program. 


*/ 

#include  <stdio.h> 

#include  <sto-ib.h> 

#include  <assert.h> 

#include  <alloc.h> 
tinclude  <string.h> 

#include  "thesis. h" 

# include  "entity.h" 

/♦ - ♦/ 

/*  Current  entity  being  created  */ 

//  static  T.entity  current_entity ; 
static  TP_entity  current_entity_list; 

/* - ♦/ 

void  entity _list_clear(void) 

{ 

current_entity_list  =  HULL; 

> 

void  entity_add(void) 

TP_entity  new_node; 

if(  (new_node  =  (TP_entity) (malloc(sizeof{T_ entity))))  ==  HULL  )  { 
yyerrorC'Out  of  memory  in  E* riTY_ADD()") ; 
exit(104) ; 

} 

new_node->id  =  ideut_get(); 

new_node->port_list  =  HULL; 
new_node->next  =  current_entity_list; 

current_entity_list  =  new_node; 

> 

void  entity_add_port(void) 

{ 

current_entity_list->port_list  =  port_get(); 

} 

void  entity_c_list_print(void) 

{ 
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entity_print(c\irrent_entity_list) ; 

} 

void  entity_list_print(TP_entity  list) 

{ 

if (list  ==  HULL)  { 

putsC'Empty  entity  signal  list"): 

> 

else  -( 

while (list  !=  HULL  )  i 
entity_print(list) ; 
list  =  liat->next: 

} 

> 


void  entity_print(TP_entity  list) 

{ 

if (list  ==  HULL)  { 

putsC'Empty  entity  signal  list"); 

} 

else  -( 

printf ("Entity  id:  "); 
ident_print(  Jt(list->id)  ); 
puts(""): 

puts("Entity  signal  list"); 
port_print(  list->port_list) ; 
putsC - ") 

} 

} 

//  Return  pointer  to  entity  specified  by  ID 
//  Return  HULL  if  not  found 
TP_entity  entity_get(int  id) 

TP_entity  ptr  =  current_entity_list; 
while (ptr  !=  HULL  M  ptr->id  !=  id)  •( 
ptr  =  ptr->next; 

> 

assert (ptr  !=  HULL); 
return  ptr; 

} 

/♦ - 
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E.IS  GENERATE.H 

// 

// 

//  File:  GEHERATE.H 

// 

// 

//  23  July  1992 

// 

// - 

#ilndel  _ generate_h _ 

#define  _ generate.h _ 

♦/ 
*/ 


generate_got_top_id(int  top_id) ; 
generate_got_top_entity_id(int  id) ; 
generate_got_top_arch_id(int  id); 

#endil 


/* - 

/* - 

/*  Prototypes  ♦/ 

void  generate_entity_iiame(int  entity.name) ; 
void  generate_arch_nane(int  arch.id); 
void  generate_ident_list(void) ; 
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E.14  GENERATE.CPP 


// 

// 

//  File:  GENERATE. C 

// 

// 

//  22  July  1992 

// 

//  This  module  handles  the  mcode  generation  for  Calvin. 

// - - 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <conio.h> 

#include  "thesis.h" 

#include  "entitjr.h" 

#include  "arch.h" 

#include  "comp_in.h" 

#include  "misc.h" 

•include  "behave. hpp" 

•include  "signal. hpp" 

•include  "comsen.hpp" 

/* - */ 

//  Static  variables 

static  int  top_id;  //  lame  of  top  configuration 

static  int  top_entity_id;  //  Entity  for  top-level  circuit 

static  TP_entity  top.entity;  //  Pointer  to  top-level  entity 

static  int  top_arch_id;  //  Arch  for  top-level  circuit 

static  TP_arch  top_aurch;  //  Pointer  to'  top-level  arch 

static  int  current.conf ig_id;  //  Current  configuration  id 

static  int  save_ent_id;  //  Temp  storage  for  current  entity 

static  int  save_arch_id;  //  Temp  storage  for  current  arch 

TP_port  G.commands ; 

TP_port  G_sensors ; 

/* - 

void  so_far(void) ; 

/* - 

//  Save  name  of  configuration 
generate_got_top_id(int  id) 

{ 

//  printfC" - COIFIGURATIOI  •/.2d".id); 

top_id  =  id; 

> 

/♦ - 

//  Save  name  of  entity  for  top  configuration 
generat e_got_top_ent ity _ id ( int  id) 

SignsdRecord  sr; 


*/ 

*/ 
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char  title [MAX_HAME_SIZE+10]: 


top_entity_id  =  id; 
top_entity  =  entity_get(id) ; 

TP_port  port_list  =  top_entity->port_list; 
while (port_list  !=  NULL)  { 

switch (  port_list->direction  )  { 
case  V_IH; 

sprintf (title , " IN _ #)(d" . port_list->id) ; 

sr  =  SigiialRecord(port_list->id,title,COMMAID_SR) ; 
add_comiiiand(port_list->id) ; 
add_signal_rec(sr) ; 
break; 
case  V_OUT: 

sprintf  (title ,  “Oin_it7A‘‘ ,  port_list->id) ; 
sr  =  SignalRecord(port_list->id, title, SEISOR_SR) ; 
add_sensor(port_list->id) ; 
add_sign2d_rec(sr) ; 
break ; 
default ; 

yyerror( "Illegal  direction  in  generate_coai_sig") ; 

} 

port.list  =  port_list->next; 

> 

> 

/* - ♦/ 

//  Save  name  for  top  arch 
generate_got_top_arch_id(int  id) 

SignalRecord  sr; 

top_arch_id  =  id; 
top_arch  =  arch_get(id) ; 

TP_signal  signal.list  =  top_arch->8ignal_li8t; 
while(signal_list  !=  HULL)  { 

sr  =  SignalRecord(signal_list->id,"x" ,-987) ; 

add_signal_rec(sr) ; 

signal.list  =  signal_list->next; 

} 

> 

/* - */ 

//  Found  entity  name  to  instantiate  with 
void  generate_entity_name(int  entity_name) 

save_ent_id  =  entity.name; 

} 

/♦ - ♦/ 

//  found  so-ch  name  to  instantiate  with 
void  generate_arch_name(int  arch.id) 
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{ 

s*ve_arch_id  =  arch_id; 

} 

/* - */ 

void  create_behave(  int  behave_id,  TP_arch  arch_ptr  ) 

{ 

Behave  bb ; 

SignalRecord  sr_ptr; 

bb  =  Behave (behave.id) ; 

bb . set_block_id(arch_ptr->id) ; 

TP_comp_in8t  this.comp  =  comp_inst_get(behave_id,  top_arch->coBp_iiist_list) ; 
TP_portmap  portmap  =  this_comp->portiBap; 

TP_assoc  assoc  =  portinap->assoc_list; 
vhileC  assoc  !=  MULL  )  { 

1 1  Find  comp  that  matches  this  comp 

TP_comp  comp  =  comp_get(  this_comp->eatity ,  top_arch->comp_list) ; 

TP_port  port  =  port_get(  assoc->left,  comp->port) ; 
sr_ptr  =  get_signal_rec(assoc->right) ; 
svitchC  port->direction)  { 
case  V_II; 

bb.add_input(assoc->right ,port->number) ; 
sr.ptr . add_conns(behave_id) ; 
break; 
case  V_0UT: 

bb . add.output (assoc->r ight ,port->anmber ) ; 
sr.ptr . set_dr iver.bi (behave.id) ; 
break; 
default: 

yyerror( "Illegal  direction  in  (generate) create  behave"); 

} 

mod_signal_rec(sr_ptr) ; 
assoc  =  assoc->nezt; 

} 

add.behave  inst(bb); 

} 


void  generate_ident_list(void) 

TP_arch  arch.ptr  =  arch_get(  save_arch_id  ); 

TP_ident_list  id_ptr  =  ident_list_get() ; 

while (  id_ptr  !=  HULL  )  { 

create_behave(  id_ptr->id,  arch_ptr  ); 


id_ptr  =  id_ptr->next ; 

} 

> 

/♦ - ♦/ 

/* - - - ♦/ 
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d 


E.15  IDENT.H 

/■t‘#define  __DEBUG__*/ 
/* 

VHDL  PARSER 
File:  IDENT.H 


Date:  2  July  1992 


This  module  handles  the  identifiers  encountered  by  BISON. 
Routines : 


ident_list_clear() — 
ident_list_free()  — 
ident_list_add()  — 
ident_list_print() — 

ident_list_get()  — 
ident_set() 
ident_get() 
ident_print(  ) 


Clear  current  identifier  list 
Free  memory  of  supplied  ident  list  ptr 
Add  current  ident  to  current  identifier  list 
Print  supplied  ident  list.  If  CURRENT_LIST , 
prints  out  current  ident  list. 

Return  pointer  to  current  ident  list 
Set  identifier  to  supplied  string 
Return  hash  value  of  current  identifier 
Print  out  supplied  identifier 


*/ 

/* - */ 

#ifndef  ident _h 

#define  ident _h 1 

typedef  int  T.ident ; 


/♦  Ident  node  ♦/ 
typedef  struct  S.ident  -( 

T_ ident  id; 

struct  S_ident  *next; 

}  T_ident_list ; 

/*  Ident  node  pointer  */ 

typedef  T_ident_list  ♦  TP_ident_list ; 


/♦  prototypes  */ 

void  ident_list_clear(void} ; 

void  ident_list_freo(TP_idont_list  list); 

void  ident_list_add(void) ; 

void  idont_list_print(TP_ident_list  list); 

TP_ident_li8t  ident_list_get(void) ; 

void  ident_set(char  es) ; 

T_ident  ident_get(void) ; 

void  ident_print(  T.ident  eid  ); 

void  ident_save(void) ; 


198 


T_ident 

void 

void 

void 

int 

#def ine 


/♦ - 

#endil 


ident_save_get(void) ; 
ident_c_list_print() ; 
ideiit_c_list_lree() ; 

lit_set(char  *str); 
lit_get(void) ; 

MAX_IDENT_LEK  32  I*  Maximum  length  of  an  identifier  *t 


*/ 
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E.16  WENT.  CP  P 

/*#deline  _ DEBUG _ ♦/ 

/* 

VHDL  PARSER 
File:  IDEIT.C 
Date:  2  July  1992 

This  module  handles  the  identifiers  encountered  by  BISOI. 


*/ 

tinclude  <stdio.h> 
tinclude  <string.h> 

#include  <8tdlib.h> 

#include  <alloc.h> 

#include  "thesis. h" 

#include  "ident.h" 

/* - */ 

/*  Storage  for  current  identifier  */ 

static  char  identifier [MAX_IDEHT_LEH+l3 ; 

static  T.ident  id.value; 
static  T.ident  save.ident; 

/♦  Storage  for  current  identifier  list  */ 

static  TP_ident_list  ident_signal_list  =  BULL; 

/♦  Storage  for  current  integer  lit  */ 
static  int  int_lit_value  =  -1; 

/♦ - ♦/ 

void  ident_list_cloar(void) 

{ 

ident.signal.list  =  HULL; 

} 

void  idont_c_list_freo() 

{ 

ident_list_free(ident_signal_list) ; 

} 

void  ident_list_free(TP_ident_list  list) 

i 

TP_ident_list  ptr; 

uhiledist  f=  HULL)  { 
ptr  =  list->next; 
free(list) ; 
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list  =  ptr; 


} 

} 


void  ident_list_add(void) 

TP_ident_list  nea.node ; 

il(  (nev.node  =  (TP_ident_list)(malloc(sizeof(T_ident_list))))  ==  MULL  )  { 
yyerrorC'Out  oi  menory  in  IDEIT_ADD_ID()''); 
exit(105) ; 

} 

neH_node->id  =  id«nt_g«t(); 
neH_node->next  =  ident_signal_list; 
ident_signal_list  =  nev.node; 

} 

void  ident_c_list_print() 

{ 

puts ("Printing  current  list:"); 
ident_list_print(ident_signal  list) ; 

} 

void  ident_list_print(TP_ident_list  list) 

ilClist  ==  HULL)  { 

putsC'Empty  ident  signal  list"); 

} 

else  { 

whiledist  !=  HULL  )  { 

ident_print(  *(list->id)  ); 

prin«("  "); 

list  =  list->next; 

> 

} 


TP_ident_list  ident_list_get (void) 

i 

return  ident_signal_list; 

} 


/* - */ 

void  ident_set(char  *8) 

stmcpy( identifier,  s,  HAX.IDENT.LEN) ; 
identifier [MAX_IDEHT_LEH]  =  ’\0'; 
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id_ value  =  atoiCidentifier+l) ; 

> 

T_ident  ident_get(void) 

id_  value  =  atoi(identilier-t-l) ; 
return  id_ value; 

> 

void  ident_print(  T_ident  *id  ) 

{ 

printl('7.d",*id); 

> 

void  ident_save(void) 
save_ident  =  id.value; 

> 

T_ident  ident_save_get(void) 

{ 

return  save.ident; 

} 


/* - 

void  lit_set(char  *8tr) 

{ 

int_lit_value  =  atoi(str); 

> 

int  lit_get(void) 

{ 

return  int_lit_value; 


} 


E.n  MCODE.H 


I* 

VHDL  PARSER 
File:  MCODE.H 
Date:  7  July  1992 
Routines: 


incode_clear_list()  —  Clear  current  mcode  list  pointer 
mcode_add_id()  —  Add  current  id  to  current  mcode  list  ! ! !IOT  USED 

mcode_add_id_list()  —  Add  current  id_list  to  current  mcode  list 
mcode_print(list)  —  Print  specified  mcode  list.  If  CURREHT.LIST , 


print  current  mcode  list. 

mcode_get()  —  Get  pointer  to  current  mcode  list. 

*/ 

/♦ - 

#ifndef  _ mcode.h _ 

#define  mcode _h 1 


#ifndef  _ ident.h _ 

#include  "ident.h" 
#endif 


/♦  Port  mcode  node  ♦/ 
typedef  struct  S.mcode  { 
int  code ; 

struct  S.mcode  *prev; 
struct  S.mcode  *'next; 

}  T_mcode; 

/♦  Port  mcode  node  pointer  */ 
typedef  T_mcode  *  TP_mcode; 

/* - 

/<•>  Codes  for  MCODE  commands  */ 

//  !!!!!!  MERGE  WITH  MCODE.H  !!!!!!! 

#define  M.IULL  -1  //  Hull  opcode 

•define  M_GET  -2  //  Get  signsd  (signal  #) 

•define  M.POST  -3  //  Post  signal  (signal  #.  value,  delta  time) 

•define  M.PUSH  -4  //  Push?? 

•define  M_IOT  -5  //  HOT  (value) 

•define  M.AHD  -6  //  AHD  ( value 1,  value2) 

•define  M_0R  -7  //  OR  (valuel,  value2) 

•define  M_XOR  -8  //  XOR  (valuel,  valne2) 

•define  M_ERD  -9  //  End  execution 

•define  M.HAHD  -10 

•define  M_H0R  -11 
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#deline  M_POP  -12 
#define  M.STORE  -13 
#d®fine  M_RETRV  -14 


//  Pop  <md  discard  top  value  on  stack 

//  Store  (addr)  —  Place  TOS  in  temp  store 

//  Retrieve  (addr)  —  Place  value  from  store  on  TOS 


/* - 

/*  prototypes  */ 

void  mcode_clear_list(void) : 

void  mcode_list_free(TP_mcode  list); 

void  mcode_add(int  nev.code) ; 

int  mcode_pop(TP_mcode  *mod_list) ; 

void  mcode_pop_top(TP_mcode  elist) ; 

TP_mcode  0code_begin(TP_mcode  list); 
void  mcode_print(TP_mcode  list); 

TP.mcode  mcode_get(void) ; 
void  mcode_c_pop_top(void) ; 
void  mcode_c_list_free(void) ; 
int  mcode_c_pop(void) ; 

TP_mcode  mcode_c_bogin(void) ; 
void  mcode_c_print(void) : 

/♦ - 

#endif 
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E.18  MCODES.CPP 


/* 

VHDL  PARSER 
File:  Bcode.C 
Date:  7  July  1992 

This  module  handles  the  microcode  generation. 

*/ 

#include  <stdio.h> 

#include  <stdlib.h> 
include  <malloc.h> 

#include  "thesis. h" 
tinclude  "mcode.h" 

#include  "misc.h" 

/♦ - ♦/ 

/«  Storage  for  current  mcode  mcode  list  */ 

static  TP .mcode  mcode.list  =  lULL; 

/♦ - ♦/ 

void  mcode_clear_list(void) 

{ 

mcode.list  =  NULL; 

> 

void  mcode.c_list.froe(void) 

{ 

mcode.list_free(mcode_list) ; 

} 

void  mcode_list_free(TP.mcode  list) 

TP .mcode  ptr; 

uhiledist  !=  NULL)  { 
ptr  =  list->prev; 
free(list) ; 
list  =  ptr; 

} 

} 


void  mcode.addCint  new.code) 

{ 

TP.mcode  neu.node; 

if(  (new.node  =  (TP.mcode) (malloc(sizeof(T_incode))))  ==  NULL  )  { 
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yjrerrorC'Out  of  Bemory  in  PORT_ADD_ID()‘*) 
exit (123) ; 

> 

new_n.ode->code  =  new_code; 

neH_node->prev  -  BCode_list ; 

neH_node->next  =  MULL ; 

if (mcode_list  !=  lULL)  { 

■code_list->next  =  ne«_node; 

> 

Bcode.list  =  neB_node; 


int  incode_c_pop(void) 

{ 

return  ncode_pop(taicode_li8t) ; 

} 

int  mcode_pop(TP_Bcode  *Bod_list) 

{ 

TP_mcode  list  =  ♦BOd_list; 
TP_mcode  old.node; 
int  node. value ; 

if (list  ==  lULL  )  { 
return  ERROR; 

} 

/♦  Pop  top  node  off  list  */ 
old.node  =  list; 
list  =  list->prev; 

if(  list  !=  ROLL)  { 
list->noxt  =  lULL; 

} 

/*  Return  changed  list  */ 
if(aiod_li8t  ==  CURREHT.LIST)  { 
Bcode.list  =  list; 

} 

else  { 

♦mod.list  =  list; 

} 

/*  Get  value  of  node  */ 
node. value  =  old.node  ->code; 

/*  Free  the  old  node  */ 
free (old.node) ; 

return  node. value; 

} 

/♦  pop  and  discard  top  of  list  ♦/ 
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void  mcode_c_pop_top(void) 

i 

mcode_c_pop() ; 

> 

void  mcode_pop_top(TP_incode  *list) 
mcode_pop(list) ; 

} 

TP.mcode  mcode_c_begin(void) 

•C 

return  mcode_begin(mcode_list) ; 

> 

TP_mcode  ncode_begin(TP_mcode  list) 

if (list  ==  FULL)  { 
return  HULL; 

} 

Bhile(list->prev  !=  HULL  )  { 
list  =  list->prev; 

} 

return  list; 

} 

void  incode_c_print(void) 

puts ("Printing  current  mcode  list:"); 
mcode_print(mcode_list) ; 

> 

void  mcode_print(TP_mcode  list) 

{ 

if (list  ==  HULL)  i 

putsC'Empty  mcode  mcode  list"); 

> 

else  { 

list  =  mcode_begin(list) ; 
Hhiledist  !=  HULL  )  { 
switch(list->code)  { 
case  M_GET : 

puts("Get_signal") ; 
break; 

case  11_P0ST: 
putsC'Post") ; 
break; 
case  N_AHD: 
puts ("And") ; 
break ; 
case  H_0R: 
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puts ("Or"); 
break; 

case  M_HAND: 
puts ("Hand") ; 
break; 
case  N_HOR: 
putsC'Hor"); 
break; 
case  M_XOR: 
putsC’Xor"); 
break ; 
case  M_IOT: 
putsC'Hot") : 
break; 
case  M_EHO: 
puts ( "End" ) ; 
break ; 
case  M_POP: 
puts ("Pop"); 
break; 

case  M_STORE: 
puts ("Store") ; 
break; 

case  M_RETRV: 

puts ("Retrieve") ; 
break ; 
default: 

print!  (  " :  y.d\n" ,  list->code) ; 

} 

list  =  list->next; 

} 

} 

} 

TP.mcode  mcode_get(void) 

{ 

return  mcode_c_begin() ; 

} 

/* - */ 
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E.19  MISC.H 

/* 

VHDL  PARSER 
File:  MISC.H 
Date:  2  July  1992 

Miscellaneous  routines  for  functions  called  from  BISOH 
Routines: 


direct_set()  —  Set  parsed  direction 

direct_get()  —  Get  current  direction 

type_set()  —  Set  current  type 

type_get()  —  Get  current  type 

*/ 

/♦ - ♦/ 

#ifndef  _ misc_h _ 

♦define  _ misc.h _  1 

/♦ - */ 

/*  Constants  */ 

♦define  V_IM  1  /*  Port  direction  IS  */ 

♦define  V_OUT  2  /*  Port  direction  OUT  */ 

♦define  V.BIT  3  /♦  Type  mark  BIT  */ 

/♦ - ♦/ 


/*  prototypes  */ 

♦ifdef  __BORLAHDC__ 

Toid  direct_set(int  new.dir) ; 
int  direct_get(void) ; 
void  type_set(int  new_type) ; 
int  type_get(void) ; 

♦else 

void  direct_set() ; 
int  direct_get() ; 
void  type_sot(); 
int  type_get ( ) ; 

♦endif 


*/ 


/* - 

♦endif 


E.20  MISC.CPP 


VBDL  PARSER 
File:  MISC.C 
Date:  2  July  1992 

Miscellaneous  routines  lor  lunctions  called  from  BISOI 


*/ 

#include  "thesis. h" 

#include  "nisc.h" 

/* - */ 

/*  Storage  lor  current  values  */ 

static  int  current_port_direction; 
static  int  current_type_mark ; 

/* - - */ 

/*  Routines  lor  handling  current  port  signeil  direction  */ 

void  direct_set(int  new_dir) 

current_port_direction  =  neu.dir; 

} 

int  direct_get() 

return  current _port_direction; 

> 

/* - ♦/ 

/*  Routines  lor  handling  current  type  mark  ♦/ 

void  type_set(int  new_type) 

{ 

current _type_mark  =  new.type; 

} 

int  type_get() 

{ 

return  current_type_mark; 

} 


E.21  PORT.H 


/* 

VHDL  PARSER 
File:  PORT.H 
Date:  2  July  1992 

This  module  handles  the  creation  of  a  port's  list  of 
input/output  signals.  Theses  functions  are  called  by  the  BISOH 
program. 

Routines : 


port_clear() 
port_add_id() 
port_add_id_list ( ) 
port _pr int ( 1 i s t ) 


port.getO 

*/ 

/* - 

#ifndef  _ port_h _ 

#define  _ port_h _  1 


Clear  current  port  list 

Add  current  ident  to  current  port  list  ! ! !  HOT  USED 
Add  current  ident.list  to  current  port  list 
Print  supplied  port  list.  If  CURREIT_LIST , 
print  out  the  current  list. 

Get  pointer  to  current  list. 


*/ 


#ifndof  ident _h 

#include  " ident. h" 
#endif 


/*  Port  signal  node  */ 
typedef  struct  S_port  { 

T_ ident  id; 

int  number; 

int  direction; 

int  ^yp«; 

struct  S_port  enext; 

>  T_port ; 

/*  Port  signal  node  pointer  */ 
typedef  T_port  ♦  TP_port; 

/* - */ 

/*  prototypes  ♦/ 

void  port_clear(void) ; 
void  port_add_id(void) ; 
void  port_add_id_list(void) ; 
void  port_print(TP_port  list); 

TP.port  port_get(void) ; 
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TP^port  port_get ( int  id,  TP.port  ptr); 

/♦ - ♦/ 

#endif 
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E.22  PORT.CPP 


!* 

VHDL  PARSER 
File:  PORT.C 
Date:  2  July  1992 

This  module  handles  the  creation  of  a  port's  list  of 
input/output  sign€Lls.  Theses  functions  are  called  by  the  BISOR 
program . 

♦/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <assert.h> 

#include  <malloc.h> 

#include  “thesis. h" 

#include  "port.h" 

#include  "misc.h" 

/* - */ 

/*  Storage  for  current  port  signal  list  ♦/ 

static  TP_port  port_signal_list  =  lULL; 
static  int  in_port_count  =  0; 
static  int  out_port_count  =  0; 

/* - */ 

void  port_clear(void) 

{ 

port_signal_list  =  HULL; 

in_port_count  =0;  //  Current  port  location  number 

out_port_count  =0;  //  Current  port  location  number 

}  ~  ~ 

void  port_add_id(void) 

{ 

TP.port  nes.node; 

if(  (new.node  =  (TP_port){raalloc(sizeof (T_port))))  ==  HULL  )  { 
yyerrorC'Out  of  memory  in  P0RT_ADD_ID()”) ; 
ezit(124) ; 

> 

nes_node->id  =  ident_get(); 

8Bitch(neH_node->direction)  { 
case  V_IH: 

new_node->number  =  in_port_count++; 
break; 
case  V_0UT: 

nes_node->number  =  out_port_count++; 
break; 


213 


default : 

putsC'M!!!  Illegal  direction  in  port_add_id,  port.cpp"); 
exit (125) ; 

> 

new_node->next  =  port_signal_list; 
port.signal.list  =  nen.node; 


void  port _add_id_li8t (void) 

TP_port  neo.node ; 
TP_ident_list  nev.list ; 
TP_idont_list  lst_ptr; 


new.list  =  lat_ptr  =  ident_list_get() ; 


} 


«hile(  l6t_ptr  !=  MULL  )  { 

il(  (new.node  =  (TP.port) (malloc(sizeof (T_port))) )  ==  MULL  )  { 
yyerrorC'Out  of  memory  in  PORT_ADD_ID_LIST()’') ; 
exit (126) ; 

> 


new_node->id  =  lst_ptr->id; 

new_node->direction  =  direct_get() ; 
awitch(new_node->direction)  < 
case  V_II: 

nev_node->nufflber  =  in_port_count++ ; 
break; 
case  V_0UT: 

neu_node->number  =  out_port_count++; 
break; 
default: 

putsC'!?!!!  Illegal  direction  in  port_add_id_list ,  port.cpp"); 
exit(127) ; 


new_node->type 
nen_node->next 
port _s ignal.l ist 
l8t_ptr 


=  type_get(); 

=  port_8ignal_list; 
=  new .node; 

=  lst_ptr->next ; 


> 

ident_li8t_froo(neu_list) ; 


void  port_print(TP_port  list) 

•C 


if (list  ==  MULL)  { 

putsC'Empty  port  signal  list") ; 

} 


else  { 

if (list  ==  CURREMT.LIST  )  { 

putsC'Pound  CL;  printing  current  list: 
list  =  port.signal.list; 


"): 
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} 

while (list  !=  HULL  )  { 
printf ("Hame:  "); 
ident_priiit(  *(list->id)  ); 
printf ("  #:y.2d“,list->niUBber) ; 
printf ("  Dir:  '■): 
snitch(list->direction)  •( 

case  V_II:  printf ("II  ");break; 
case  V_OUT:  printf ("OUT") ; break; 
default :  printf ( "Unknown”) ; 

> 

printf ("  Type:  BIT"); 
puts(""); 

list  =  list->next; 

> 

} 

> 

TP_port  port_get(void) 

{ 

return  port_signal_list; 

> 

/♦ - */ 

//  Return  pointer  to  port  specified  by  id  in  supplied  port  list 

//  Return  HULL  if  not  found 

TP_port  port_get(int  id,  TP_port  ptr) 

while(ptr  !=  HULL  tk  ptr->id  !=  id)  { 
ptr  =  ptr->next; 

} 

if(  ptr  ==  HULL  )  { 

printfC! ! ! ! !  Error  -  Couldn't  find  port  ’/.d  (PORT.CPP  L141)",id); 
exit (128) ; 

} 

ret\im  ptr; 

} 

/♦ - ,/ 
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E.P.S  PORTMAP.H 


VHDL  PARSER 
File:  PORTMAP.H 


Date:  9  July  1992 


This  module  hauidles  the  creation  of  a  portmap’s  list  of 
input/output  signals.  Theses  functions  are  called  by  the  BISOH 
program. 

Routines : 


portmap.clear ( ) 
portmap_add_id() 
por tmap_  add_ id_list() 
portmap.pr int (list) 


portmap.get ( ) 

*/ 

/* - 

#ifndef  _ portmap.h _ 

#define  _ portmap.h _  1 


—  Clear  current  portmap  list 

—  Add  current  ident  to  current  portmap  list  D 

—  Add  current  ident.list  to  current  portmap  list 

—  Print  supplied  portmap  list.  If  CURRE1T_LIST , 
print  out  the  current  list. 

—  Get  pointer  to  current  list. 


*/ 


#ifndef  _ assoc.h _ 

#include  "assoc.h" 
#endif 


/*  portmap  signal  node  */ 
typedef  struct  S.portmap  { 

TP_assoc  assoc.list; 

struct  S_portmap  *next; 

}  T.portmap; 

/*  portmap  signal  node  pointer  */ 
typedef  T_portmap  ♦  TP .portmap; 

/♦ - */ 

/*  prototypes  */ 

/* - ♦/ 

void  portmap_list_clear(void) ; 
void  portmap_list_free(TP .portmap  list) ; 
void  portmap.list.add.nodo(TP.assoc  list); 
void  portmap.list. print (TP.portmap  list); 

TP.portmap  portmap.get(void) ; 

/* - ♦/ 

#endif 
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E.24  PORTMAP.CPP 

/♦ 

VHDL  PARSER 
File:  PORTMAP.C 
Date:  9  July  1992 

This  Bodule  handles  the  creation  of  a  portmap's  list  of 
input/output  signals.  Theses  functions  are  celled  by  the  BISOI 
program. 

♦/ 

#include  <stdio.h> 

#include  <stdlib.h> 

#include  <assert.h> 

#include  <B2dloc.h> 

#include  "thesis. h" 

#include  "portmap.h" 

#include  "misc.h" 

/* - */ 

/*  Storage  for  current  portmap  signal  list  */ 

static  TP.portmap  portmap_list  =  HULL; 

/* - */ 

void  portfflap_list_clear(void) 

portmap.list  =  HULL; 

} 

void  portBap_list_free(TP_portmap  list) 

TP.portmap  ptr; 

ifdist  ==  CURREHT_LIST)  { 
list  =  portmap.list; 

> 

whileClist  !=  HULL)  •[ 
ptr  =  list->next; 
freeClist) ; 
list  =  ptr; 

} 

} 

void  portBap_list_add_node(TP_assoc  list) 

TP_portmap  neu.node; 

if(  (neu_node  =  (TP_portmap)(malloc(si2eof (T_portmap))))  ==  HULL  )  { 
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vyerrorC'Out  of  memory  in  portmap_ADD_ID()") ; 
exit(107): 

} 

new_node->assoc_li8t  =  list; 
new_node->next  =  portmap.list; 

portmap_list  =  nen.node; 

} 

void  portmap_list_print(TP_portmap  list) 

if (list  ==  HULL)  { 

putsC'Empty  portmapiation  list*'); 

} 

else 

if (list  ==  CURREHT.LIST  )  i 

putsC'Fouild  CL;  printing  current  portmap  list:"); 
list  =  portmap_list; 

> 

Hhiledist  !=  NULL  )  { 

puts ("Association  list:"); 
assoc_list_print(  list->assoc_list) ; 
list  =  list->next; 

} 

} 

} 

TP_portmap  portmap_get(void) 

{ 

return  portmap.list; 

} 


E.25  PROCESS.  H 


VHDL  PARSER 
File:  PROCESS. H 


Date:  14  July  1992 

This  module  handles  the  creation  of  an  process  by  the 
VHDL  parser.  These  routines  are  called  by  the  BISOH  prograun. 

Routines : 


process_clear()  —  Clear  current  process  settings 
process_add_mcode()  -  Add  current  mcode 

process_print()  -  Print  out  specified  process  -  HULL  prints 
out  current  process 

*/ 

/* - */ 

#ifndef  _ process_h _ 

#define  _ process_h _  1 

#ifndef  _ mcode_h _ 

#include  "mcode. h" 

#endif 

typedef  struct  S.process  •{ 

TP_mcode  mcode ; 

}  T_process ; 

#ifdef  _ process_c _ 

T.process  HULL.PROCESS  ={HULL}; 

#else 

extern  T.process  IULL_PROCESS ; 

#endif 


/*  prototypes  */ 


void 

void 

T.process 

void 

void 

int 

int 

void 

void 

void 

void 


process_clear(void) ; 
proce8s_add_mcode(void) ; 
process_get(void) ; 
process_c_print(void) ; 
proce8s_print(  T_process  fent) ; 
create_c_sim_process(void) ; 
create_sim_process(T_proce8S  ♦proc) ; 
new_8im_block(int  arch_id); 

add_code_to_8im_block(int  code_id,  char  ♦code_title) ; 
f inish_sim_block(void) ; 
create_all_hypo(void) ; 
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/♦ — 
#eadil 


E.26  PROCESS.  CPP 


/* 

VHDL  PARSER 
File:  PROCESS. C 
Date:  14  July  1992 

This  module  handles  the  creation  of  an  process  by  the 
VHDL  parser.  These  routines  are  called  by  the  BISON  program. 
Fault  hypotheses  eire  also  added  in  this  module. 


*/ 

tdefine  _ process_c _  1 

#include  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 

#include  <string.h> 

#include  "thesis.h" 

#include  "process. h" 

#include  "block. hpp" 

#include  "code. hpp" 

/* - 

/*  Current  process  being  created  */ 

static  T_process  current .process ; 

/* - 

void  process_clear(void) 

{ 

current .process. mcode  =  NULL; 

> 

/♦ - 

void  process.add.mcode(void) 

current. process,  mcode  =  mcode.getO; 

} 

/* - 

T.process  process.get(void) 

return  current .process; 

} 

/♦ - 

void  process. c.print (void) 

process.print(kcurrent. process) ; 

> 

/* - 

void  process.printC  T.process  *ent) 

{ 


*/ 


*/ 


*/ 


*/ 


*/ 


*/ 
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if(  ent->mcode  ==  NULL  )  { 
putsC'Hull  Process"); 

> 

else  { 

puts ("process  ncode  list"); 
acode_print (  ent->«code) ; 

} 

} 

/♦ - 

/♦ - */ 

//  Create  code-structure  lor  siaulator  use.  This  routine  sill  tcdce  the 
//  supplied  code  process  and  create  a  CODE  block.  This  routine  uill  be 
//  called  by  create_si«_block() 

int  create_c_siB_process(void) 

{ 

return  create_sin_process(ftcurrent_process) ; 

} 

int  create_sim_process(T_process  ♦proc) 

static  int  code.count  =0;  //ID  for  neu  code  block;  return  value 
Code  code.block; 

code.block  =  Code (code. count); 

T.mcode  vmcode.ptr  =  proc->BCode; 

while  (acode.ptr  !=  NULL  )  ■( 

code.block. add.mcode (MCode(mcode_ptr->code) ) : 
mcode.ptr  =  mcode.ptr->next ; 

} 

add.code.block(code.block) ; 
return  code.count++ ; 

} 

/* - */ 

//  Storage  for  new  sim  block  object 

static  block  new.block; 

void  new.sim.blockdnt  arch.id) 

new.block  =  block(arch.id) ; 

> 

void  add_code_to.sim.block(int  code.id,  char  *code. title) 

{ 

new.block. add.code(code.id,  code.title) ; 

} 
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void  linish_siiB_block(void) 

{ 

add_block_inst (nes.block) ; 

} 

/* - 

int  hypo_in_stuck_hi(  Code  tgood_code,  int  get .number) 

{ 

int  mcode.pos  =  0; 
int  code_get_no  =  N.IULL; 
int  lound_get  =  FALSE; 
char  title_str[MiX_STR_LEI+l] ; 

MCode  mcode.rel; 

mcode_clear_list () ; 
process.clearO ; 

while (  mcode.pos  <  good_code.get_code_blk_len())  { 
mcode.ref  =  good_code.get_mcode_at(mcode_pos) ; 
if(  mcode.ref .get_op_code()  ==  M_GET  )  ■{ 
il(code_get_no  ==  get .number)  { 

mcode_add(ll.P0P) ;  //  Remove  signal  offset 

mcode.addCD ;  //  Stuck  HI 

found.get  =  TRUE; 

} 

else  { 

mcode_add(mcode_ref  .get.op.codeO) ; 

} 

} 

else  { 

fflcode.addCmcode.ref  .get.op.codeO) ; 

> 

code_get.no  =  mcode.ref .get.op.codeO ; 
mcode_po8++ ; 

} 

if (found_get)  { 

process.add.mcodeO ; 

sprintf (title.str,  "Input  #%d  stuck  hi  ", get .number ) ; 
add_code_to_sim_block(create_c_sim_processO ,  title.str) ; 

} 

return  found.get; 


/♦ - 

int  hypo_in_8tuck_low(  Code  tgood.code,  int  get.number) 

{ 

int  mcode.pos  =0; 
int  code.get.no  =  N.IULL; 
int  found.get  =  FALSE; 
char  title.str [MAX.STR.LEI+l] ; 

MCode  mcode.ref; 
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■code_cle2u:_list() ; 

process_clear() ; 

«hile(  mcode.pos  <  good_code.get_code_blk_leii())  ■( 
mcod«_ref  =  good_code.get_mcode_at(mcode_pos) ; 
il(  Bcode.ref .get_op_code()  ==  M_GET  )  { 
il(code_get_no  ==  get.nunber)  ■{ 

Bcode_add(M_POP) ;  //  Remove  signal  ollset 

Bcode_add(0) ;  //  Stuck  LOW 

lound_get  =  TRUE; 

} 

else  { 

Bcode_add(Bcode_rel .get_op_code()) : 

> 

> 

else  -C 

Bcode_add(mcode_rel .get_op_code()) ; 

} 

code_get_no  =  mcode.ref .get_op_code(); 

Bcode  pos-t-i-; 

} 

if(found_get)  < 

process_add_mcode() ; 

sprintf  (title_str ,  "Input  #*/,d  stuck  low",  get  .number ) ; 
add_code_to_sim_block(create_c_siB_process() ,  title.str) ; 

} 

return  iound.get; 

} 

- - - 

int  hypo_out_stuck_hi(  Code  kgood.code,  int  post  number) 

{ 

int  mcode.pos  =  0; 

int  iound.post.no  =  0; 

int  lound.post  =  FALSE; 

Chau:  title.str[MAX_STR.LEH+l] ; 

NCode  Bcode.rel; 

mcode.clear.listO ; 

process.clearO ; 

uhileC  mcode.pos  <  good.code.get.code.blk.lenO)  { 
mcode.ref  =  good_code.get.mcode.at(mcode.pos); 
if(  mcode.ref .get. op.codeO  ==  M.POST  )  { 
if (found_post.no  ==  post.number)  { 

mcode_add(0) ;  //  Temp  store  auldr  to  save  time 

mcode_add(M_STORE} ;  //  Store  delta  time 
mcode.addCM.POP) ;  //  Remove  old  value 

mcode.addCl);  //  Stuck  BI 

mcode_add(0) ;  //  Temp  store  addr 

mcode_add(M_RETRV) ;  //  Get  stored  delta  time 
mcode.addCM.POST) ;  //  POST 

found.post  =  TRUE; 
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> 

else  { 

mcode_add(mcode_ref .get_op_code()) ; 

} 

found_post_no++ ; 

> 

else  { 

■code_add(Eicode_ref .get_op_code{)) ; 

> 

mcode_po8++ ; 

} 

if (lound_post)  { 

process_add_mcode( ) ; 

spriiitl(title_str,  "Outut  #y.d  stuck  hi  ".post_nuaber) ; 
add_eode_to_sim_block(create_c  sim.processO ,  title  str); 

> 

return  found.post; 


int  hypo_out_stuck_low(  Code  kgood_code,  int  post  nuaber) 

{ 

int  mcode.pos  =  0; 
int  found_post_no  =  0; 
int  found_post  =  FALSE; 
char  title_str[MAX_STR_LEH+l]; 

KCode  acode.rel; 

mcode.clear.list ( ) ; 
process_clear ( ) ; 

ohileC  mcode_pos  <  good_code.get_code_blk_len())  { 
mcode.ref  =  good_code.get_mcode_at(mcode_pos) ; 
il(  mcode_ref .get_op_code()  "  M_P0ST  )  { 

if (found_post_no  ==  post .number)  { 

mcode_add(0) ;  //  Temp  store  addr  to  save  time 

mcode.add (N_ STORE) ;  //  Store  delta  time 
mcode_add(M_P0P) ;  //  Remove  old  value 

ncode_add<0) ;  //  Stuck  LOW 

mcode_add(0) ;  //  Temp  store  addr 

mcode.add (M_ RETRY) ;  //  Get  stored  delta  time 
mcode.add(M.POST) ;  //  POST 

found.post  =  TRUE; 

} 

else  { 

mcode.add  (mcode.ref  .get. op.codeO) ; 

} 

f ound.post.no++ ; 

} 

else  { 

mcode.add(mcode.ref  .get.op.codeO) ; 

> 
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mcode_pos++ ; 

> 

if (found_post)  { 

proces8_add_mcode() ; 

sprint!  (title_str,  "Qntnt  #*/,d  stuck  Ion"  .post .number) ; 
add_code_to_sim_block(create_c_sim_process() ,  title.str) ; 

} 

return  found.post; 

} 

/* - ♦/ 

//  The  working  model  of  a  process  is  defined  as  code  #0 
tfdefine  WORKIltG.MODEL  0 

void  create_all_hypo(void) 

{ 

int  get.no, 
post.no; 

Code  kcode.ptr  =  get_code_block(nen_block.get.code(WORKIIG.MODEL)) ; 

//  Hypothesize  inputs  of  component  stuck  high 
post.no  =0; 

nhileC  hypo.out_stuck.hi  (code.ptr,  post_no++))  •£} 

//  Hypothesize  inputs  of  component  stuck  Ion 
post.no  =  0; 

nhile(  hypo_out_stuck_lon(code_ptr,  post_no++))  {} 

//  Hypothesize  inputs  of  component  stuck  high 
get.no  =  0; 

Hhile(  hypo.in.stuck.hi  (code.ptr,  get_no++))  O 

//  Hypothesize  inputs  of  component  stuck  Ion 
get .no  =  0; 

nhile(  hypo_in_stuck_lon(code_ptr,  get.no++))  {} 

} 
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E.27  SIGNAL.H 


VHDL  PARSER 
File:  SIGRAL.H 


Date:  7  July  1992 
Routines: 


s ignal_clear_list ( ) 
s ignal _add_ id () 
signal_add_id_list() 
signal _print(list) 


signal_get() 

*/ 

/♦ - 

#ilndef  _ signal.h _ 

#define  s ignal _h 1 


Clear  current  signal  list  pointer 
Add  current  id  to  current  signal  list  ! ! !10T  USED 
Add  current  id.list  to  current  signed  list 
Print  specified  signal  list.  If  CURREIT.LIST, 
print  current  signal  list. 

Get  pointer  to  current  signal  list. 


*/ 


#ifndef  _ ident.h _ 

#include  "ident.h" 
#endif 


/*  Port  signal  node  */ 
typedef  struct  S.signal  { 

T.ident  id; 

int  • 

struct  S.signal  enext; 

>  T.signal; 

/*  Port  signal  node  pointer  */ 
typedef  T_s ignal  ♦  TP_s ignal; 

/* - „/ 

/•  prototypes  */ 

#ifdef  __B0RLA1IDC__ 
void  signal_clear_list(void) ; 

void  signal_add_id(void) ; 

void  signal_add_id_list(void) ; 

void  signal_print(TP_signal  list) ; 

TP.signal  signal_get(void) ; 

#else 

void  signal_clear_list() ; 

void  signal_add_id() ; 

void  signal_add_id_list() ; 

void  signal_print() ; 

TP_signal  signal_get() ; 
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#endil 


/♦ - */ 

#endif 
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E.28  SIGNALP.CPP 


/* 

VHOL  PARSER 
File:  SIGNAL. C 
Date:  7  July  1992 

This  Bodule  handles  the  creation  of  signals. 

*/ 

tinclude  <stdio.h> 

#include  <stdlib.h> 

#include  <Balloc.h> 

#include  “thesis. h" 
tinclude  "signal. h" 
tinclude  "misc.h" 

/* - */ 

/♦  Storage  for  current  signal  signal  list  */ 

static  TP.signal  signal.signal.list  =  HULL; 

/* - ♦/ 

void  signal_clear_list(void) 

{ 

signal.signal.list  =  NULL; 

} 

void  signal_add_id(void) 

{ 

TP_signal  new.node; 

if(  (nev.node  =  (TP_signal)(Balloc(sizeof(T_8igneJ.))})  ==  HULL  )  { 
yyerrorC'Out  of  memory  in  PORT_ADD_ID()") ; 
exit (108) ; 

> 

neB_node->id  =  ident_get(); 

neB_node->next  =  signal_signal_list; 

8ignal_signal_list  =  new.node; 

> 

void  8ignal_add_id_list(void) 

TP_8ignal  new.node; 

TP_ident_li8t  new.list ; 

TP_ident_list  l8t_ptr; 

neB_li8t  =  l8t_ptr  =  ident_li8t_get() ; 

whileC  l8t_ptr  !=  HULL  )  { 

if(  (new.node  =  (TP_8ignal) (malloc(sizeof (T_8ignal))))  ==  HULL  )  { 


yyerrorC'Out  of  nemory  in  SIGH1L_ADD_ID_LIST()") ; 
exit (109) ; 

} 

new_node->id  =  lst_ptr->id; 

ne»_node->type  =  type_get(); 

neH_node->next  =  signal.signal.list; 

signal_sigaal_list  =  nev.node; 

lst_ptr  =  lst_ptr->next ; 

} 

ident_list_lree(ne«_list) ; 


void  signal_print(TP_signal  list) 

if (list  ==  MULL)  { 

putsC'Empty  signal  signal  list"): 

> 

else  { 

if (list  ==  CURREIT.LIST  )  { 

putsC'Found  HILL;  printing  current  signal  list:"); 
list  =  signal_signal_list: 

> 

Bhiledist  !=  lULL  )  { 
printf ("Name:  "); 
ident_print(  *(list->id)  ); 
printf ("  Type:  BIT"); 
putsC") ; 

list  =  list->next; 

} 

> 

} 

TP_signal  signal_get(void) 
return  signal_signal_list; 

> 
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Appendix  F.  Simulator/Diagnostic  Source  Code 


F.l  Overview 

This  appendix  contains  the  code  for  Calvin’s  VHDL  simulator  and  diagnostic  routines.  A 
module  generally  consists  of  a  header  file  and  associated  code  file.  These  have  the  same  or  similar 
names,  with  a  “.hpp”  extension  for  the  header  and  a  “.cpp”  extension  for  the  code  file.  The 
following  modules  were  discussed  in  Chapter  III; 

•  BEHAVE  -  section  3. 3. 4. 6 

•  BLOCK  -  section  3. 3. 4. 7 

•  CODE  -  section  3.3.4. 8 

•  MCODE  -  section  3.3.4.9 

•  SIGNAL  -  section  3.3.4.5. 

The  following  modules  handle  specific  minor  tasks; 

•  COMSEN  -  manage  the  lists  of  commands  and  sensors 

•  INT  -  A  Object  shell  for  an  integer.  This  module  was  required  so  that  integer  values  could 
be  used  with  Borland’s  container  library. 

•  STAT  -  This  module  collected  the  statistics  discussed  in  section  4.1.1. 

•  THESIS  -  This  module  contained  the  various  constants  used  throughout  the  simulator/diagnostic 
routines. 

The  module  MAIN  contains  Calvin’s  user  interface.  Here  is  were  Calvin  parses  the  command  line, 
and  where  Calvin’s  system  flags  are  set.  Calvin  opens  the  source  file,  and  sends  it  to  the  VHDL 
parser.  Calvin  then  calls  the  diagnostic  routines  contained  in  the  module  named  CALVIN. 


232 


The  VHDL  module  is  Calvin’s  VHDL  simulator.  Most  of  the  VHDL  simulation  routines 


are  gathered  here.  This  module  uses  the  signal,  behave,  block,  and  code  objects  to  perform 
the  simulation.  The  simulation  is  controlled  by  a  function  at  the  end  of  the  VHDL  module, 
vhdlunainJoopO  .  The  activation  record  used  by  the  VHDL  simulator  is  defined  in  the  module 
AR. 

The  diagnostic  routines  are  gathered  into  the  module  CALVIN.  These  routines  include 
suspect  collection  and  fault  insertion.  The  main  diagnostic  algorithm  is  also  in  CALVIN. 


F.2  AR.HPP 

// 

//  AR.HPP 

// 

//  Activation  Record  Class 

// 

//  Modified  16  July  1992 

// 

#ifndef  __AR_HPP„ 

#d€fine  _ AR.HPP _  1 

#include  <sortable.h> 

#define  ActiveRecordClass  222 

class  ActiveRecord  :  public  Sortable  { 
public: 

ActiveRecordO  { 
time  =  -1; 

sr.ptr  =  -1; 

value  =  -1; 

> 

ActiveRecord(int  nev.time,  int  new.sr.ptr,  int  new. value)  { 
time  =  new.time; 

sr.ptr  =  new.sr.ptr; 

value  =  new. value; 

} 

int  get_sr_ptr(void)  { 
return  sr.ptr; 

} 

int  get. value (void)  { 
return  value; 

} 
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int  get_tiiae(void)  { 
return  time; 

} 

virtual  int  isEquaK  const  Objects  otherObj  )  const  { 
retxirn  time  ==  ( (ActiveRecordt)  otherObj) .time; 

} 

virtual  int  isLessThanC  const  ObjectA  otherObj  )  const  { 
return  time  <  ((ActiveRecord  A)  otherObj) .time; 

} 

virtual  classType  isA()  const  {return  ActiveRecordClass ; } 

virtual  char  ♦nameOfO  const  {return  "Active  Record";} 
virtual  hashValueType  hashValueO  const  { 
return  time; 

} 

virtual  void  printOn(  ostreamA  coutt  )  const  { 

coutt  «  "Time:  "  «  time  «  "  srptr:  "  «  sr_ptr 
«  "  Value:"  «  value; 

> 

private: 

int  time; 
int  sr_ptr; 
int  value ; 

>; 

#endif 
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F.3  BEHAVE.HPP 


// 

// 

U  BEHAVE.HPP 
// 

//  Behave  Class 

// 

//  16  July  1992 

// 

//  Behavie  instemce  object 

// 

// - 

#iuclude  "thesis. h" 

#define  MAX.CODE  20  //  Nazimum  number  of  bodies  lor  behave 

#deline  NAX_BEHAVE_IIST  40  //  M2ix  number  of  behaviors  in  simiilation 

class  Behave  { 
public: 

Behave () ; 

BehaveCint  netr.id) ; 

int  get_id(void) ;  //  Get  id  number 

void  set_code_8elect(int) ;  //  Select  code  lor  execution 

int  get_current_select(void) ;//  Get  current  code  nuber 

void  set_block_id(int) ;  //  Set  block  id  to  exec  lor  this  behave 

int  get_block_id(void) ;  //  Get  block  id  to  exec 

int  get_code_count(void) ;  //  Return  number  ol  bodies 

void  add. input ( int ) ;  //  Add  nee  input  to  input  list 

void  add. input (int, int ) ;  //  Add  nee  input  to  position  in  list 

int  get.input(int) ;  //  Get  input  id 

int  get.input.count(void) ;  //  Return  number  ol  inputs 

void  add.output(int) :  //  Add  new  output  to  output  list 

void  add.output(int,int) ;  //  Add  nee  output  to  position  in  list 

int  get.output(int) ;  //  Get  output  id 

int  get.output.count(void) ;  //  Return  number  ol  outputs 

void  print(char  ♦) ;  //  Debug  print 


private: 

int 

id; 

//  Int  name  ol  behave 

int 

block. id; 

//  ID  ol  block  to  exec  lor  this  behave 

int 

code.select; 

//  Current  code  lor  Behave  execution 

int 

input [MAX.IH]; 

//  List  ol  inputs  to  Behave 

int 

last. in; 

//  Last  input  added 

int 

output [HAX.OUT] ; 

//  List  ol  outputs  Irom  Behave 

int 

last.out : 

//  Last  output  added 

}; 
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// - 

//  Behave  instance  storage  management  routines 


void 

void 

int 

int 

Behave 

void 

void 

void 

int 

// - 


reset _behave_inst (void) ; 
add_behave_inst(  Behave  tnes.behave) ; 
get .last _behave_inst (void) ; 

get_behave_id_at(int  pos);  //  Get  behave  it  at  position 
tget_behave_inst(int  id); 
behave_inst_print(char  es); 

f lush_behave_mark(void) ; 
mark_behave(int  id); 
is_behave_marked(int  pos); 
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F.4  BEHAVE.CPP 
// 

//  BEHAVE.CPP 

// 

//  Behave  Class 

// 

//  16  July  1992 

// - 

#include  <stdio.h> 

#include  <conio.h> 

#include  <stdlib.h> 

#iiiclude  <assert.h> 

#include  "behave . hpp" 

#include  "block. hpp" 

// - 

//  Storage  for  Behave  instance 

static  Behave  behave.storage CMAX_BEHAVE_IIST3 ; 
static  int  behave_mark[MAX_BEHAVE_IHST3 ; 
static  int  last_behave_inst ; 

// - 

//  Local  function  prototypes 
int  translate_id_to_pos(int  id); 

// - 

//  Clear  behave  instance  mark  list 
void  flush_behave_mark(void) 

for(int  i=0;i<HAX_BEHAVE_IirST:++i)  { 
behave_mark[i]  =  FALSE; 

} 

> 

// - 

//  Nark  a  behave  instance 
void  mark_behave(int  id) 

{ 

behave_mark[translate_id_to_pos(id)]  =  TRUE; 

> 

// - 

//  Return  aark  status  of  a  behave 
int  is_behave_marked(int  id) 

{ 

return  behave_mark[treuislate_id_to_pos(id)] ; 

> 

// - 

// - 

void  reset_behave_inst(void) 

i 

last_behave_inst  =  0; 

} 
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// - 

void  add_behave_inst(  Behave  Anew.behave) 

assert (last_behave_inst<NAX_BEHAVE_IHST) ; 
behave.storageClast.behave.inst-i-t-]  =  ne«_behave; 

} 

// - 

int  translate_id_to_pos(int  id) 

lor(int  i=0;  i<last_behave_iiist ;  ++i)  { 
il(  behave_storage[i] .get.idO  ==  id  )  { 
return  i; 

> 

> 

print! (“Invalid  id  numbr  #y.d  in  translate_id_to_pos()\n“,id) ; 
exit(l) ; 
return  -1 ; 

} 

// - 

Behave  Aget_behave_inst(int  id) 

for(int  i=0;  i<last_behave_inst;  ++i)  { 

if(  behave.storageCi] .get_id()  ==  id  )  { 
return  behave.storageCi] ; 

> 

> 

printK" !  ! ! !  M  Bad  id  ‘Xd’in  get_behave_inst - behave.  cpp\n" , id) ; 

exit(l) ; 

return  behave_storage[0] ; 

} 

// - 

int  get_behave_id_at(int  pos) 

< 

return  behave_storage[pos] .get_id(); 

> 

// - 

int  get _last_behave_inst (void) 

{ 

return  last.behave.inst; 

} 

// - 

void  behave_inst_print(char  •s) 

{ 

print! (s) ; 

lor (int  i=0;  i<last_behave_inst ;  ++i)  { 

print! (" - behave  inst  y,2d - \n",i); 

behave.storageCi]  .printC") ; 
getchO ; 

} 

puts(" - ”); 

} 
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//================================================== 

Behave: :Behave() 

{ 

id  =  0; 

last.in  =  la8t_out  =  0; 
code_select  =  0; 

> 

// - 

Behave: ; Behave (iat  nev.id) 

{ 

id  =  nev_id; 

last.ia  =  last.out  =  0; 

code_8elect  =  0; 

> 

// - 

int  Behave: :get_id(void} 

i 

return  id; 

} 

// - 

void  Behave: :set_code_select (int  new.code.select) 

{ 

code.select  =  new_code_select ; 

} 

// - ^ - 

int  Behave: :get_current_select(void) 

{ 

return  code.select; 

} 

// - 

void  Behave: : set _block_id(int  new_block_id) 

block_id  =  new_block_id; 

> 

// - 

int  Behave: : get _block_id(void) 

i 

return  block_id; 

> 

// - 

int  Behave: :get_code_count(void) 

return  get_block_inst (block_id) . get_code_count ( ) ; 

} 

// - 

void  Behave: :add_input( int  input.id) 

assert (last.in  <  HAX_IN) ; 

input [last_in++]  =  input_id; 

} 


239 


// - 

void  Behave: :add_iiipnt(int  input.id,  int  input.pos) 

{ 

assert (input _pos  <  NAX.II); 

input [input _pos++]  =  input_id; 
if ( input _pos>=last_in)  < 
last_in  =  input_pos; 

} 

> 

int  Behave: :get_input( int  input.no) 

t 

assert (input_no<last_in) ; 
assert (input_BO>=0) ; 

return  input [input.no] ; 

} 

// - 

int  Behave : : get .input. count (void) 

C 

return  last.in; 

} 

// - 

void  Behave: :add.output( int  output.id) 

{ 

assert (last.out  <  MAX.OUT); 
output [last.out++]  =  output.id; 

> 

// - 

void  Behave: :add.output( int  output.id,  int  output.pos) 

{ 

assert (output.pos  <  MAX.OUT); 

output [output .pos++]  =  output.id; 
il  (output .pos>=la8t.out)  •[ 
last.out  =  output.pos; 

} 

> 

// - 

int  Behave: : get .output (int  output.no) 

il (output.no  >=  last.out)  •[ 

printlC'ERR:  this=)^d  output.no=%d  last.out=Xd\n" ,  id. output .no, last. out) 
exit(-l) ; 

} 

assert (output .no<last. out) ; 
assert (output _no>=0) ; 

return  output [output.no] ; 
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} 

// - 

int  Behave : : get_output_coimt (void) 

return  last.out; 

} 

// - 

void  Behave: : print (char  es) 

{ 

printl(s) ; 

printl ("Behave  id:  %2d  Block  id:*/, 2d  Current  code:  y,2d\n",id, 
block_id,code_select); 
putsC'Inputs: ") ; 
for(int  i=0; i<last_in;++i)  { 

printf (’"/,2dl  input  id  y,2d\n", i, input [i]); 

> 

puts ( "Outputs : " ) ; 
for(i=0;i<last_out;++i)  ■[ 

printf ("*/.2d I  output  id  •/.2d\n", i, output [i] ) ; 

} 

> 

// - 
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F.5  BLOCK.  HPP 


// 

// 

//  BLOCK. HPP 

// 

//  Process  Block  Class 

// 

//  30  July  1992 

// - 

#ilndel  _BL0CK_HPP_ 

#deline  _BL0CK_HPP_ 

#deline  NAX.CODES  20  //  Maximum  number  of  code  bodies  for  block 

#define  HAX_BL0CK_IHST  10  //  Max  number  of  blocks  in  simulation 

♦define  MAX_STR_LEK  20 

// - 

class  block  { 
public: 

block (int  id); 
block(void) ; 

"blockO ; 

int  get_id(void) ; 
void  add. code (int, char  *) ; 
int  get.code ( int ) ; 
int  get_code_count(void) : 
char  ♦hyp_str_get(int) ; 
void  print(char  es); 
private: 

int  id ; 

int  sim_code_idCMAX_CODES] ;  //  VHDL  microcode  code  number 

char  hyp_str[MAX_CODES] [MAX_STR_LEI+l3 ;  //  Strings  for  hypothesis' 

int  last_code_no;  //  Last  code  number  added 

}; 

// - 

//  block  instance  storage  management  routines 

void  reset_block_inst(void) ; 

void  add_block.inst(  block  tnew.block); 

int  get_last_block_inst(void) ; 

int  get_block_id_at(int  pos);  //  Get  block  it  at  position 

block  Aget_block_inst(int  id); 
void  block_inst_print(char  *s) ; 

// - 

#endif 


//  Constructor 

//  Destructor 

//  Get  id  number 

//  Add  neu  code  to  code  list 

//  Get  code  id 

//  Return  number  of  bodies 

//  Return  hypothesis  title 

//  Print  block  description 

//  Int  name  of  block 


name 
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F.6  BLOCK. CPP 


II 

II 

//  BLOCK. CPP 

// 

//  Process  Block  Class 

// 

//  30  July  1992 
// - 

#include  <stdio.h> 

#include  <conio.h> 

#iQclade  <stdlib.h> 

#iaclude  <string.h> 
tiaclude  <alloc.h> 
tiaclude  <assert.h> 
tiaclude  "block. hpp" 

// - 

//  Storage  lor  block  iastaace 

static  block  block_storage[MAX_BLOCK.INST] ; 
static  iat  last.block.iast ; 

// - 

block: :block(iat  aeu.id) 

{ 

id  ®  aew_id; 

la8t_code_BO  =  0; 

//  Clear  all  hypothesis  strings 
forCint  i=0;i<l!AX_C0DES;++i)  { 
strcpy(hyp_str[i] ,  " - ") ; 

} 

} 

block: :block(void) 

{ 

id  =  “1; 

last_code_no  =  0; 

//  Clear  all  hypothesis  strings 
lor (iat  i=0;i<MAX_CODES;++i)  < 
8trcpy(hyp_str[i] ,  " - "); 

} 

} 

block: : 'block 0 

//  priatl ( "BLOCK :: 'DELETE  y.p\n"  .this)  ;getch()  ; 

> 

// - 

iat  block: :get_id( void) 

{ 

return  id; 

} 
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// - 

void  blocX: :add_code(iiit  code.id,  char  ♦new_hyp_str) 

{ 

assert(last_code_no  <NAX_COOES) ; 
siBi_code_idClast_code_no]  =  code_id; 

stmcp3r(hyp_strClast_cod«_no] ,  neH_hyp_str,  M1X_STR_LEM); 
last_code_no++ ; 

} 

// - 

char  *block: :hyp_8tr_g«t(iiit  nuaber) 

{ 

return  hyp.str [nuaber] ; 

> 

// - 

int  block: :get_code(int  code_no) 

assert (code_no<last_code_no) ; 
assert (code_no>=0) ; 

return  sia_code_idCcode_no] ; 

> 

// - 

int  block: :get_code_count(void) 

< 

return  la8t_code_no; 

} 

// - 

void  block: :print(char  *s) 

print! (s) ; 

print! ( "Block  id:  %2d\n" , id) ; 
putsC'Codes:"); 

!or(int  i=0;i<last_code_no;++i)  { 

print!("%2dl  code  id  */l2d\n",i,sim_code_id[i]) ; 

} 

} 

// - 

// - 

void  reset _block_inst (void) 

{ 

last.block.inst  =  0; 

> 

// - 

void  add_block_inst(  block  kneu.block) 

{ 

assert (last_block_inst<MAX_BLOCK_INST) ; 
block_storage[last_block_inst++]  =  nes.block; 

} 

// - 

block  tget_block_inst(int  id) 
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{ 

lordnt  i=0;  i<last_block_  inst ;  ++i)  {. 
if(  block.storageCi] .get_id()  ==  id  )  { 
return  block.storage [i] ; 

} 

} 

print! ("!!!!!!  Bad  id  I %2d I  in  get_block_inst - block . cpp\n" , id) ; 

exit(116) ; 

return  block.storage [0] ; 

> 

// - 

int  get_block_id_at(int  pos) 

return  block.storage  Cpos]  .get.idO; 

} 

// - 

int  get .last _block_inst (void) 

{ 

return  last_block_inst ; 

} 

// - 

void  block. inst .print (char  *s) 

< 

print! (s); 

!or(int  i=0:  i<last_block.inst;  ++i)  < 

print! (" - block  inst  yt2d - \n'',i); 

block.storage [i]  .printC") ; 
getchO ; 

} 

putsC'-- r - ")  ; 

} 

//================================================================== 

// - 

// - 


245 


F.7  CALVIN.CPP 


// 

// 

//  CALVIN.CPP 

// 

//  16  Jul  92 

// 

//  This  module  is  where  most  of  the  modules  that  make  up  the  current 
//  configuration  of  Calvin.  During  developement .  routines  were  created 
//  using  this  module.  As  they  were  completed,  they  were  spawned  off  into 
//  their  own  modules.  The  current  state  of  Calvin  developement  is  in  this 
//  module. 

// 

// 

// 

//  void  print_bi_queue()  —  Debuge  routine 

//  int  get_bi_from_signal()  —  Get  the  Behave  that  drives  the  signal 

//  void  init_suspect_queue()  —  init  queue 

//  void  collect_bi_suspects()  —  Original  depth-lst  collection  routine 
//  void  sus_depth_lst(int  sr_id)  — + 

//  void  collect _bi_suspects_2(  int  sr_id  )  — +-  Modified  collection  routine. 

//  Break  when  encounter  a  Behave  that  is  already  in  the  queue. 

// 

//  These  routines  make  up  the  suspect  collection  part  of  Calvin. 

// 

// 

//  void  sim_signal_init(void)  --  init  routine 

//  void  sim_set_up()  —  init  routine 

//  int  sensor.compO  —  Compare  simulated  sensors  with  outside  sensors 

//  void  load_out_val()  —  Get  outside  sensor  values 

//  void  faultify_behave()  —  "Break”  the  circuit. 

//  void  diagnoseO  —  The  Diagnose  algorithm 

//  void  run_exam()  -  Run  Calvin 

// - 

// 

#include  <stdio.h> 

#include  <conio.h> 

Ninclude  <assert.h> 

Ninclude  <string.h> 

#include  <stdlib.h> 

Ninclude  <queue.h> 

Ninclude  "thesis.h" 

Ninclude  "signal. hpp" 

#include  "behave. hpp" 

#include  "block. hpp" 

#include  "code. hpp" 

#include  "int. hpp" 

#include  "vhdl.hpp" 
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#include  “coasen.hpp" 

#iiiclude  "stat.hpp" 

// - 

Queus  bi.queue;  //  Queue  of  Behave  Instance  suspects 

// - 

//  Debug  function  to  print  suspect  BI  queue 
void  print_bi_queue(void) 

Queue  temp.q  =  bi.queue; 

putsC'Queue  of  Behavioral  Instance  suspects"): 

HhileC  iteap.q.isEmptyO)  { 

cout  «  teap.q.getO  «  endl; 

} 

putsC - ") ; 

exit(O) ; 

> 

// - 

//  Get  BI  id#  of  instance  that  drives  specified  signal 
int  get_bi_froB_signal(int  sr_id) 

SignalRecord  4sr_ptr  =  get_signal_rec(sr_id) ; 
return  sr_ptr.get_driver_bi() ; 

} 

// - 

//  Flush  out  the  suspect  queues 
void  init_suspect_queue(void) 

{ 

bi.queue . flush ( ) ; 

> 

// - 

//  Collect  list  of  suspects  froa  a  possible  discrepaoit  signal 
//  Uses  depth  first  approach 

//int  level  =  0; 

void  collect_bi_suspects(  int  sr_id) 


Integer  *suspect_bi; 

suspect_bi  =  new  Integer (get_bi_froB_signal(sr_id) ) ; 

//  Make  sure  we’re  not  at  the  top  (command  level) 
if {suspect_bi->value()  !=  C0MMAMD_SR)  { 
bi_queue.put(  esuspect.bi) ; 

//  Recurse  upstreaa  froa  behave  instance 
Behave  *bi_ptr  =  get_behave_inst(su8pect_bi->value()) ; 
for(  int  i=0;  i<bi_ptr .get_input_count();++i)  { 
collect _bi_suspects (bi_ptr .get_input(i) ) ; 
inc_8tat(lfO_SUSPECTS) ; 
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} 

} 

else  -C 

//  puts ("Reached  command  level"); 

> 


// - - - 

void  sus_depth_lst(int  sr_id) 

{ 

Integer  esuspect.bi; 

suspect.bi  =  neu  Integer(get_bi_from_signal(sr_id)) ; 

//  N2Lke  sure  ue're  not  at  the  top  (commeoid  level) 
ii( suspect _bi->value()  !=  COMMAHD_SR)  •( 

//  Make  sure  suspect  not  in  queue  already 
il(  ! is_behave_marked(suspect_bi->value())  )  •{ 
mark.behave ( suspect _bi-> value ( ) ) ; 
bi_queue . prt (  *suspect_bi) ; 

//  Recurse  upstream  from  behave  instance 
Behave  tbi_ptr  =  get_behave_inst{suspect_bi->value()) ; 
for(  int  i=0;  i<bi_ptr .get_input_count() ;++i)  { 
sus_depth_lst (bi_ptr.get_ input (i) ) ; 
inc_stat(MO_SUSPECTS) ; 

} 

} 

} 

else  { 

//  putsC'Reached  command  level"); 

} 

} 


void  collect _bi_suspects_2(  int  8r_id  ) 

{ 

llush_behave_mark( ) ; 
init_suspect_queue() ; 
sus_depth_lst(sr_id) ; 

> 


// - 

void  sim_signal_init(void) 

{ 

process.initO ; 
vhdl_main_loop( ) ; 

} 
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// - 

void  siin_set_up( 
int  ♦in_val, 
int  iii_val_last  ) 

for (int  i=0:i<in_val.last;++i)  { 

post_signal(0,get_coBBiand(i) ,*(in_val+i)) ; 

} 

} 

// - - - 

//  Compare  simulated  values  (out.val)  uith  recorded  (rec.val) 
//  Return  TRUE  if  same,  FALSE  if  not 
int  sensor_comp( 
int  ♦out.val , 
int  ♦rec_val , 
int  out_val_last  ) 

{ 

for (int  i=0; i<out_val_last;++i)  { 
if  (out_v«d.[i]  !=  rec_val[i3)  { 
return  FALSE; 

} 

} 

return  TRUE; 

} 

// - 

void  load_out_val( 
int  ♦out.val , 
int  out_val_last  ) 

for(int  i=0;i<out_val_last;++i)  {. 

SignalRecord  si_ptr  =  get_signal_rec(get_sensor(i)) ; 
*(out_v2d+i)  =  si_ptr .get_cval() ; 

} 

} 

// - 

void  faultify_behave( 
int  bi_id, 
int  *in_val, 
int  in_val_last , 
int  ♦out_val, 
int  out_val_last , 
int  *reo_val  ) 

{ 

Behave  *bi_ptr  =  get_behave_inst(bi_id) ; 
if(  is_flag_set(PRI»T_HYPO))  { 

printfC'For  ’/,2d,  we  have  y,d  bodies. \n", 
bi_id,  bi_ptr.get_code_count()); 

} 

for(int  i=l;i<bi_ptr.get_code_count();  ++i)  < 
if(is_flag_set(PRIMT_HYPO))  { 

printf ("Selecting  fault  condition  #%d\n",i); 
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} 

//  Hypothesize  error 
bi_ptr.set_code_select(i) ; 
inc_stat(HO_HYPO_CHECKED) ; 

//  Re-simulate 
sim_signal_init() ; 
sim_set_up(in_v2Q. , in_val_la8t) ; 
vhdl_main_loop( ) ; 

load_out_val(out_val ,out_val_last) ; 

//  Compare  outputs 

if ( sensor_comp(out_val ,rec_val , out_Tal_last ) )  { 
if(is_flag_set(PRIHT_TRIV))  { 

printf("»»»  Found  a  Suspect:  at  5Cd  «««\n", 

(get_block_inst(  bi_ptr.get_block_id()  ) .hyp_str_get(i)  ), 
bi_id  ) ; 

> 

else  { 

printf("y,s  at  ‘/.d:  Suspect \n", 

(get_block_inst(  bi_ptr.get_block_id()  ) .hyp_str_get(i)  ), 
bi_id  ) : 

} 

inc_stat(IO_FAULTS_FOUin)) ; 

} 

else  { 

if(is_flag_set(PRIHT_HYPO))  { 

printf ("Ruled  out  hypothesis  y.d\n",i); 

> 

} 

//  Clear  fault 

bi_ptr . set_code_select (0) ; 

} 

} 

// - 

void  diagnose ( 
int  *in_val, 
int  in_val_last , 
int  ♦out_val, 
int  out_val_last , 
int  *rec_val  ) 

{ 

int  i; 

int  found_problem  =  FALSE; 

//  Set  up  commands 
sim_set_up(in_val,in_val_last) ; 
vhdl_main_loop() ; 

//  Get  simulated  values 
load_out_val (out_val , out_val_last) ; 
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if(is_flag_set(PRIHT_lSIM))  { 

putsC'Correct  operation  results:”); 
for(int  j=0; j<out_val_last;++j)  { 

print! ("•/.2d:  Signal  #y.2d  =  •/.2d\n",j, 
get_sensor( j) ,out_val[j]) ; 

} 

> 

//  Check  lor  problems 
for(i=0; i<out_val_last;++i)  { 
il(out_valCi] !=rec_valCi])  { 
lound.problem  =  TRUE; 
if (is_flag_set(PRIHT_TRIV))  { 

printfC'Ue  have  a  problem  at  sensor  #X2d  (Signal  %03d):y.2d  !=  y.2d\n", 
i,get_sensor(i) ,  out_vaJ.[i] ,rec_val [i] ) ; 

} 

else  { 

print!  ("###y.3d###\n",get_sensor(i)): 

} 

i!(is_!lag_set (COLLECT _ 2)  ){ 

collect _bi_suspects_2(get_sensor(i) ) ; 

} 

else  { 

collect _bi_suspects (get _sensor(i) ) ; 

} 

i!(is_!lag_set(PRIST_SUSP)  )  { 
print_bi_queue() ; 

} 

while (  !bi_queue.isEmpty()  )  f 
!aultify_behave( 

((Integer  k)bi_queue.get()) .valueO , 
in_val , in_val_last , 
out_val,out_val_last,rec_val  ); 

} 

i!(  is_!lag_set(INSERT_BRK)  )  { 
break; 

} 

} 

} 

//  I!  no  problems  !o\md,  state  so 
i!( !!ound_problem)  { 

putsC'Ho  problems  found"); 

} 

> 

// - 

void  run_exam(void) 

int  in.val  [MAX.COMMANDS] , 
out_val [MAX.SENSORS] , 
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rec_valCMAX_SEKSORS] ; 
int  i; 

int  in_last  =  get_last_coinmand( ) ; 

int  out_last  =  get_last_sensor() ; 

//  Get  circuit  to  steady  state 
siin_signal_init() ; 

if (G_con_llag)  { 

printf ("Enter  values  for  the  y,d  command  signals :\n”,in_last); 
for(i=0; i<in_last;++i)  { 

printf ("Command  /(s;",get_signal_rec(get_command(i)} .get.nameO  ); 
scanf ( "%d" , A ( in_val [i] ) ) ; 

} 

printf  ("Enter  values  for  the  '/.d  sensor  signals :  \n".  out.last) ; 
for(i=0:i<out_last;++i)  { 

printf ("Sensor  !(s:",get_signal_rec(get_sensor(i)).get_name()  ) ; 
scanf  ("y.d",*(rec_val[i])) ; 

} 

> 

else  { 

if (is_flag_set(PRIHT_TRIV))  { 

putsC'Getting  commands, sensors") ; 

} 

for(i=0; i<in_last;++i)  { 

f  scanf (conf ile , "Xd" , *( in_val Ci] ) ) ; 
if(is_flag_set(PRIHT_TRIV))  { 

printf  ("Command  '/.s:  Xd\n",get_sign^Q_£ec(get_colnmand(i))  .get_name()  , 
in_val[i]  ); 

} 

} 

for(i=0; i<out_last:++i)  { 

f  scanf  (  conf  ile ,  "y.d" ,  ft  (rec_val  [i]  )  ) ; 
if(is_*lag_set(PRIHT_TRIV))  { 

printf  ("Sensor  '/.s :  y.d\n",get_8ignal_rec(get_sensor(i))  .get.nameO , 
rec_val[i]  ); 

} 

} 


diagnose(  in_val,in_last,out_val,out_last,rec_val) ; 


F.8  CODE.HPP 


// 

// 

//  CODE.HPP 

// 

//  Code  block  class 

// 

//  16  July  1992 

// - 

#ifndef  __CODE_HPP__ 

#define  __CODE_HPP__ 

#include  "mcode.hpp" 

#define  HAX_CODE_LEH  40  //  Hax  length  of  op  codes 

#define  MAX_C0DE_BL0CKS  40  //  Max  number  of  code  blocks 

class  Code  { 
public; 

Code (void) ; 

CodeCint  neu_id): 

int  get_id(void) ;  //  Return  ID  for  code 

void  add_mcode(MCode  neu.code);  //  Add  mcode  to  code  object 

void  executeCint  bi_no);  //  Execute  Code  block 

void  print(char  *s);  //  Print  code  description 

int  get_code_blk_len(void) ;  //  Rettirn  length  of  code 

HCode  get_mcode_at ( int  pos);  //  Get  mcode  from  code  block 
private : 

int  id;  //  Code  id  number 

MCode  code_blk[MAX_CODE_LEH] ;  //  MCode  storage 

int  last_code_no:  //  Last  NCode 

>: 

// - 

//  Code  block  storage  management  routines 

void  reset_code_block(void) ; 

void  add_code_block(  Code  kneu.code) ; 

Code  tget_code_block(int  id); 
void  code_block_print(char  *s) ; 

// - 

//  Execution  stack  routines 

void  value_reset(void) ; 
void  value_push(int  value); 
int  value_pop(void) ; 

// - 

#endif 
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F.9  CODE.CPP 

// 

// 

1 1  CODE.CPP 

// 

//  Code  block  class 

// 

//  16  July  1992 

// - 

#include  <stdio.h> 

#include  <conio.k> 

#include  <stdlib.h> 

#iuclude  <assert.h> 

#include  "code.hpp" 
tfinclude  <stacks.h> 

typedel  BI_StackAsVector<int>  intStack; 
void  Code: ;execute(int  bi_no) 

■C 

int  code_pc  =0;  //  mcode  PC 

int  not.done  =  TRUE; 

//  printl  ( "Code : :  Execute :  Behave  #y.2d\n" , bi_no) ; 
value_reset() ; 
while (not_done)  { 

not.done  =  ( ( code_blk [code.pc] ) . execute (bi_no) ) ; 
code_pc++ ; 

} 

} 

// - 

typedef  BI_StackAsVector<int>  intStack; 
intStack  value.stack; 

/*  Clear  any  remaining  values  on  value  stack  */ 
void  valuo_roset(void) 

nhile(  !value_stack.isEmpty()  )  { 
veilue.stack.popO ; 

} 

} 

void  value_push(int  value) 

{ 

value_stack.push(value) ; 

} 

int  value_pop(void) 

{ 

return  value.stack . pop( ) ; 
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> 

// - 

// - 

//  Storage  for  Code  blocks 

static  Code  code_storage[MAX_CODE_BLOCKS] ; 
static  int  last_code_block; 


void  reset_code_block(void) 

{ 

last_code_block  =0; 

} 

void  add_code_block(  Code  Anew.code) 

{ 

assert (last_code_block<l(AX_CODE_BLOCKS) ; 
code^storage[last_code_block++]  =  nev.code; 

} 

Code  kget_code.block(int  id) 

for (int  i=0;  i<last_code_block;  ++i)  { 
if(  code_storage[i]  .get_id()  ==  id  )  ■( 
return  code. storage [i] ; 

} 

} 

puts(" !!!!!!  Bad  id  in  get_code_block - code.cpp") ; 

exit(119) ; 

return  code.dtorageCO] ; 


void  code_block_print(char  *s) 

{ 

printf (s) ; 

for (int  i=0;  i<last_code_block;  ++i)  { 

printf (" - Code  block  y.2d - \n",i); 

code_storage[i]  .printC") ; 
getchO: 

} 

putsC - "); 

} 


//===============. 

Code: : Code (void) 

{ 

id  =  -1; 
last_code_no  = 

} 


0; 
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// - 

Code: : Code (int  ne«_id) 

{ 

id  =  new_id; 
last_code_Bo  =  0; 

> 

// - 

int  Code: :get_id( void) 

retun  id; 

> 

// - 

void  Code: :add_mcode(MCode  nev_code) 

assert (last_code_no<MAX_CODE_LEH); 
code_blk [last_code_iio++]  =  neu.code; 

> 

// - 

void  Code :: print ( char  vs) 

{ 

printf (s) ; 

print! ("For  Code_block  •/,2d,  MCodes  are:\n",id); 
for (int  i=0;i<last_code_no;++i)  { 
printl("*/.2dl  ",i): 
code.blk [i] . print ( ) ; 
putsC'"); 

} 

} 

// - 

int  Code: :get_code_blk_len(void) 

{ 

return  last_code_no; 

} 

// - 

MCode  Code: : get_mcode_at ( int  pos) 

return  code_blkCpos3 ; 

> 

// - 


// 
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F.JO  COMSEN.HPP 


// 

// 

//  COMSEI.HPP 

// 

//  Handle  Command  and  sensor  lists 
//  16  jul  92 
// 

// - 

// - - - 

#define  NAX.COMNAIDS  20  //  Max  number  of  commands  (system  inputs) 
#define  MAX.SEISORS  20  //  Heix  number  oi  sensors  (system  outputs) 

#define  COMMAID.SR  -1  //  Signal  is  driven  by  a  Commetnd 

#define  SEISOR.SR  -2  //  Signal  drives  a  sensor 

// - 

void  reset_commands(void) ;  //  Initialize 

void  add_command(int  signal.id) ;  //  Add  nev  command  to  list 

int  get_command(int  command_no) ;  //  Get  command 

int  get_last_command(void) ;  //  Get  the  last  command  in  the  list 

void  reset_sensors(void) ;  //  Initialize 

void  add_sensor(int  signal.id);  //  Add  nev  sensor  to  list 

int  get_sensor(int  sensor.no) ;  //  Get  sensor 

int  get_la3t_sensor(void) ;  //  Get  the  last  sensor  in  the  list 

// - 
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F.ll  COMSEN.CPP 


// 

// 

//  COMSEI.CPP 

// 

//  Handle  Command  and  sensor  lists 
//  16  jul  92 
// 

// - 

#include  <assert.h> 

#include  "comsen.hpp" 

// - 

//  Storage  for  Commands 

static  int  commands [MAX_COMMAHDS] ; 
static  int  last.command; 

//  Storage  for  sensors 

static  int  sensors [MAX.SEHSORS] ; 
static  int  last.sensor; 

// - 

void  reset_commands(void) 

{ 

last.command  s  O; 

} 

void  add_ command (int  signal.id) 

{ 

assert (last.command  <  NAX_CONNANDS) ; 
commeuids  Clast_command->-i-!]  =  signal.id; 

} 

int  get_comm2md(int  command.no) 

i 

assert ((command_no>=0)  tt  (command_no<last_command)) ; 
return  commands [command.no] ; 

} 

int  get_last_command(void) 

{ 

return  last.command; 

> 

// - 

void  reset_sensors(void) 

{ 

last.sensor  =  0; 

} 


258 


void  add_sensor(iiit  signal_id) 

{ 

assert (last_sensor  <  HAX_SENSORS) ; 
sensors [last_sensor++]  =  signal.id; 

} 

int  get_sensor(int  sensor_no) 

•C 

as8ert({sensor_no>=0)  Me  (sen8or_no<last_sen8or)) ; 
return  sensors [sensor_no] ; 

} 

int  get_last_sensor(void) 
return  last.sensor; 

} 

// - 
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F.12  INT.HPP 
// 

//  IIT.HPP 

// 

//  Integer  Class  -  for  IDs 

// 

//  This  object  puts  a  shell  around  an  integer.  It  is  required 
//  so  that  integers  can  be  used  with  the  Borland  container  library 
// 

// 

#ifndef  __IIT_HPP__ 

♦define  __IHT_HPP__  1 

♦include  <object.h> 

// 

♦define  IntegerClass  111 

class  Integer  :  public  Object  { 

public: 

Integer (int  new_data  =  0)  { 
data  =  new.data; 

> 

int  value(void)  {  return  data;  } 

virtual  hashValueType  hashValueO  const  { 
return  data; 

} 

virtual  int  isEqualC  const  Object*  otherObj  )  const  ■[ 
return  data  ==  ((Integer*)  otherObj) .data; 

> 

virtual  int  isLessThan(  const  Object*  otherObj  )  const  { 
return  data  <  ((Integer  *)  otherObj) .data; 

} 

virtual  classType  isA()  const  {return  IntegerClass;} 

virtual  char  *name0f()  const  {return  "Integer";} 

virtual  void  print0n(  ostream*  coutt  )  const  { 
coutt  «  "Int:  "  «  data; 

} 

private : 

int  data; 

}; 

// 

♦endif 
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F.13  MAIN.CPP 


// 

// 

II  MAII.CPP  -  main  function  and  supporting  routines 
// 

//  24  Aug  92 

// 

//  This  is  the  ~  in  module  of  Calvin.  This  module  handles  initializing’ 
//  Calvin.  The  VHDL  code  is  the  parsed.  Control  is  then  handed 
//  to  the  diagnostic  modulem  CALVIN. CPP. 

// - 

// 

#define  __KAII_CPP__ 

#include  <stdio.h> 

# include  <conio.h> 

#include  <assert.h> 

#include  <string.h> 

#include  <stdlib.h> 

#include  "thesis. h" 

#include  "vhdl.hpp" 

#include  "stat.hpp" 

♦define  ERR_STR_LEM  128  //  Length  of  error  string  argument  parsing 

//FILE  *infile;  //  input  file  for  source  code 

//FILE  ♦confi''.e:  //  input  file  for  commands 
//int  G_code;  //  Code  flag  for  output  options 

// - 

//  PRINT_TRIV  - 

//  Print  out  headings, etc. 

//  PRIHT.HYPO  -  T.CPP 
//  "selecting  fault  condition  %d" 

//  "Ruled  out  hypothesis  ’/.d" 

//  "For  VA,  me  have  VA  bodies" 

//  PRIIT_COMM  -  UV.LEX 
//  Print  out  comments 

//  PRIIT.ISIM  -  T.CPP 

//  print  out  results  from  first  simulation 
//  PRINT.VH"’  -  vhdL.CPP 
//  many 

//  PRIIT.SUSP  -  T.CPP 

//  print  list  of  suspects  after  collect_bi_suspects() 

//  IHSERT.BRK  -  T.cpp 

//  break  inserted  as  soon  as  error  found  and  diagnosed 
//  C0LLECT__2  -  T.cpp 

//  replace  collect_bi_suspects()  with  collect _bi_suspects2() 
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int  flags [MAX_FLAG3 ;  //  System  flags  set  by  command  line 
int  is_flag_set(int  flag_no) 
return(  flags [flag_no]  ); 

} 

void  set_flag(char  ♦flag.str) 

{ 

for(int  i=0;i<MAX_FLAG:++i)  { 

SHitch(  *(flag_str+i)  )  { 
case  ’\0' : 

yyerrorC "Hissing  Flag  on  command  line"); 
exit (99) ; 
case  ’!*: 

flags [i]  =  1; 
break; 
case  ’O': 

flags [i]  =  0; 
break; 
default : 

yyerrorC'Illegal  flag  on  command  line"); 
exit(99) ; 

} 

} 

} 

// - 

void  print_system_f lags (void) 

i 

puts ("System  flag  status:"); 

printf  ("PRIHT.TRIV:  '/.dXn"  ,  flags  [PRI»T_TRIV]  ); 
printf  ("PRIHT.HYPO:  y.d\n"  ,  flags  [PRIHT_HYPO]  ); 
printf  ("PRIKT.COMM:  ’/.dXn"  .  flags  [PRI»T_C0MM]  ); 
printf  ("PRIHT_1SIH:  '/.d\n"  .  flags  [PRIHT_1SIM]  ); 
printf  ("PRIHT.VHDL:  V.d\n"  ,  flags  [PRIIT_VHDL]  ); 
printf  ("PRIHT.SUSP:  ’/.dXn"  ,  flags  CPRIIT_SUSP]  ); 
printf  ("IKSERT_BRK:  '/.dXn"  .  flags  [IISERT.BRK]  ); 
printf  ("C0LLECT__2:  ’/.dXn"  ,  flags  [C0LLECT__2]  ); 

puts(" - "); 

> 

// - 

void  parse_code_flag(  int  argc,  char  ♦♦argv) 

{ 

char  *file_name; 

char  err_str [ERR_STR_LEM] ; 

if (argc  <  2  )  { 
putsC’Usage:")  ; 

puts("  CALVIH  ffffffff  vhdl.file  input_f ile\n")  ; 
puts ("where : 

puts("  ffffffff  -  Calvin  flags  (0/1)"); 
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puts("  vhdl_file  -  VHDL  source  code  file"); 

puts("  input_file  -  Optional  input  file  for  in/out  valuesXn"); 

puts ("Flags : ; 

puts("  0  -  Print  trivia"); 

putsC  1  -  Print  hypotheses"); 

puts("  2  -  Print  commands"); 

puts("  3  -  Print  results  of  first  simulation"); 

putsC  4  -  Print  VHDL"); 

puts("  5  -  Print  suspects"); 

puts("  6  -  Insert  breakpoint"); 

puts("  7  -  Use  Collection"); 

exit(lll) ; 

} 

else  { 

set_flag(*(argv+l)) ; 

} 

if(is_flag_set(PRIHT_TRIV))  i 
print_system_flags() ; 

} 

> 

// - 

void  parse_source_f ile(  int  argc,  char  **argv) 

{ 

char  *file_name; 

char  err_str[ERR_STR_LEH] ; 

if (argc  <  3  )  { 

putsC'Source  file  not  found;  using  \"ttt\""); 
file_n2UBe  =  "ttt" ; 

} 

else  { 

file_name  =  *(argv+2); 

} 

if(  (inf ile=fopen(file_name,"r"))  ==  HULL  )  { 

sprintf(err_str," Cannot  open  source  file  \"%s\"",  file_name); 
yyerror(err_str) ; 
exit(112) ; 

} 

> 

// - 

void  parse_input_f ile(  int  argc,  char  **argv) 

char  *file_name; 

char  err_str [ERR_STR_LEH] ; 

if (argc  <  4  )  { 

putsC'input  file  not  found;  using  \"con\""); 
file.name  =  "con"; 

G_con_flag  =  TRUE; 
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return; 


} 

else  { 

file.name  =  *(argv+3); 

G_con_flag  =  FALSE; 

} 

if(  (conf ile=lopen(f ile_naaie,"r"))  ==  HULL  )  { 

sprint! (err_str, "Cannot  open  source  file  \"*/,s\"",  file.name); 
yy error (err_str) ; 
exit(113) ; 

> 

//  Determine  number  of  inputs  lines  to  process 
if (fscanf (confile,"’/.d",*G_no_inputs)  !=  1  )  { 

yyerrorC'Syntax  error  uhile  reading  confile  header"); 
exit(114) ; 

> 

//  Eat  CRLF  at  end  of  line 
fgets(err_str,  ERR_STR_LEI,  confile); 

> 

// - 

void  main(int  argc,  char  4"*argv) 

i 

putsC'VHDL  Diagnostic  System"); 
init_sim() ; 

parse_code_flag(argc,argv) ; 
parse_source_file(argc,argv) ; 
parse_input_file(argc,argv) ; 
yyparseO ; 
if (G_con_f lag)  { 
reset_stats() ; 
run_exam() ; 
print_stats() ; 

if(is_flag_set(PRIHT_TRIV))  { 

puts("=============EHD=OF=RUN===================="); 

> 

} 

else  -C 

for(int  i=0;  i<G_no_ inputs;  ++i)  { 
reset_stats() ; 
run_exam() ; 
print_stats() ; 

if(is_flag_set(PRINT_TRIV))  { 

puts("=============END=OF=RUM========= ===========") ; 

> 

} 

} 

puts ("El  Fin."); 

> 

// - 
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F.14  MCODE.HPP 

// 

// 

1 1  MCODE.HPP 

// 

//  Microcode  class 

// 

//  Handle  execution  of  individual  acodes. 

//  16  July  1992 

// - 

#ifndef  __MC0DE_HPP__ 

#define  __MCODE_HPP__ 

// - 

#define  MAX_STORE_LEN  20  //  Hvunber  of  temp  store  locations 

//  MCodes  implemented 

#define  M_IIULL  -1  //  Null  opcode 

#define  M_GET  -2  //  Get  signal  (signal  #) 

#define  M_P0ST  -3  //  Post  signal  (signal  #,  value,  delta  time) 

#define  M_PUSH  -4  //  Push?? 

#define  M.NOT  -5  //  HOT  (value) 

#define  M_AND  -6  //  AND  (valuel,  value2) 

#define  M_0R  -7  //  OR  (valuel,  value2) 

#define  M.XOR  -8  //  XOR  (valuel,  value2) 

tdefine  M_END  -9  //  End  execution 

#define  M.HAHD  -10  //  HAND  (valuel,  value2) 

#define  M_H0R  -11  //  HAND  (valuel,  value2) 

#define  M_P0P  -12  //  Pop  (2Uid  discard)  value  on  top  of  stack 

#define  M_ST0RE  -13  //  Store  (addr)  —  Place  TOS  in  temp  store 

#define  M_RETRV  -14  //  Retrieve  (addr)  —  Place  value  from  store  on  TOS 

class  MCode  ( 
public; 

MCode (void):  //  Create  null  microcode 

MCode ( int  neH_op) ;  //  Create  new  microcode 

int  execute(int  bi_no) ;  //  Execute  the  opcode 

void  print(void);  //  print  translation  of  opcode 

int  get_op_code(void) ;  //  Return  mcode  op  code 

private: 

int  op_code; 

>; 

// - 

#endif 
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F.15  MCODE.CPP 


// 

// 

//  MCODE.CPP 

// 

//  Microcode  class 

// 

//  16  July  1992 

// 

//  This  module  handle  the  microcode  execution. 

// - 

#include  <stdio.h> 
tinclude  <conio.h> 

#include  <stdlib.h> 

#include  <assert.h> 

#include  "mcode.hpp" 

#include  "code.hpp" 

#include  "behave. hpp" 

#include  "signal. hpp" 

♦include  "vhdl.hpp" 

// - 

int  exec_null(void) ; 
int  exec_get(int  bi_no); 
int  exec_post(int  bi_no) ; 
int  exec_push(void) ; 
int  exec_not(void) ; 
int  exec_and2(void) ; 
int  exec_or2(void) ; 
int  exec_xor2(void) ; 
int  exec_end(void) ; 
int  exec_pop(void) ; 
int  exec_store(void) ; 
int  exec_retrieve(void) ; 

// - 

//  Temp  store  for  values  during  code  execution 
int  G_storeCMAX_STORE_LEK] ; 

// - 

MCode: :MCode(void) 

i 

op.code  =  M.HULL; 

} 

// - 

MCode; : MCode (int  nev_op) 

{ 

op_code  =  new_op; 

> 

// - 

MCode: : get _op_code (void) 

{ 
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return  op_code; 


} 

// - 

int  MCode; '.execute (int  bi.no) 

i 

1 1  printf ("Executing  lor  bi#%2d:  ",bi_no); 

//  printO; 

//  putsC"'); 
switch(op_code)  ■[ 
case  N_HULL: 

return  exec.nullO; 
case  H_GET: 

return  exec_get(bi_no) ; 
case  M_POST: 

return  exec_post(bi_no) ; 
case  M_PUSH; 

return  exec_push() ; 
case  M_»OT; 

return  exec_not(); 
case  H_AIO: 

return  exec_and2(); 
case  M_OR; 

return  exec_or2(); 
case  M_XQR; 

return  exec_xor2(); 
case  M.EID: 

return  exec.endO; 
case  M_P0P: 

return  exec_pop() ; 
case  M_STORE: 

return  exec_store() ; 
case  H.RETRV: 

return  exec_retrieve() ; 
default: 

if(op_code  >=  0)  { 

value_push(op_code) ; 
return  TRUE; 

} 

else  { 

printf ("*♦♦♦*  Illegal  opcode  %2d  ! ! ! ! !\n",op_code) ; 
exit(122) ; 

> 

} 

return  FALSE; 

} 

// - 

void  HCode: : print (void) 

switch(op_code)  { 
case  M.BULL; 

printf ("M_IULL"); 


267 


bresJc; 
case  M_GET: 

printf("M_GET"): 

break ; 

case  M_POST : 

printf{"M_POST"); 

break; 

case  l!_PUSH: 

printlC'M.PUSH"); 
break; 
case  M_HOT: 

printl("M_IOT"); 

break; 
case  N_AHD: 

printlC'M.AHD"); 
break; 
case  M_OR; 

printlC'M.OR"); 
break; 
case  M_XOR: 

printfC'M.XOR"); 
break; 
case  H.EHD; 

printfC'M.END"); 
break; 
case  M_P0P: 

printfC'M.POP"); 

break; 

case  M_STORE: 

print! ("M.STORE"); 
break; 

case  M_RETRV: 

print! ("M_RETRV"): 
break; 
de!ault: 

.i!(op_code  >=  0)  { 

print! ("Value ;  *>l2d"  ,op_code) ; 

} 

else  { 

print! ("fUnknown*") ; 

} 

} 

} 

// - 

// - 

int  exec_null(void) 

■C 

return  TRUE; 

} 

int  exec_get(int  bi_no) 

{ 
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Behave  *bi_ptr  =  get_behave_inst(bi_no) ; 

int  signal.ollset  =  value_pop(); 

int  signal.id  =  bi_ptr.get_input(signal_oflset) ; 

SignalRecord  tsr.ptr  =  get_signal_rec(signal_id) ; 

int  value  =  sr_ptr .get_cval() ; 

value_push(value) ; 
return  TRUE; 

} 

int  exec_post(int  bi_no) 

i 


int 

time.olfset 

=  value.popO ; 

int 

value 

=  value.popO; 

int 

signal.olfset 

=  value.popO ; 

Behave  ftbi.ptr 

=  get.behave.inst{bi.no) ; 

int 

signal.id 

=  bi.ptr .get_output(signal_ofiset) ; 

SignalRecord  *sr_ptr  =  get_signal_rec(sign2d_id) ; 

post_s ignal (get_current_t ime ( ) +t  ime_olf  set , sr_ptr . get_id( ) , value) ; 

return  TRUE; 

} 

int  exec_push(void) 

putsC I ! ! ! !  UIIMPLEMEHTED  OP  CODE  IN  MCODE”) ; 
return  FALSE; 

> 

int  exec_not(void) 

int  value  =  value_pop(); 
value_push( lvalue) ; 
return  TRUE; 

> 

int  exec_and2(void) 

int  valuel  =  value_pop(); 
int  value2  =  value_pop(); 
value_push( valuel  t  value2} ; 
return  TRUE; 

> 

int  exec_or2(void) 

{ 

int  valuel  =  value_pop(); 
int  value2  =  value_pop(); 
value_puBh( valuel  I  value2) ; 
return  TRUE; 

> 

int  exec_xor2(void) 

int  valuel  =  value_pop(); 
int  value2  =  value_pop(); 

int  values  =  ((valuel  ft  !value2)  I  (I valuel  ft  value2)); 
value_push(value3) ; 
return  TRUE; 
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} 

int  exec_end(void) 

{ 

return  FALSE; 

> 

int  exec_pop(void) 

{ 

value_pop() ; 
return  TRUE; 

} 

int  exec_store(void) 

{ 

int  addr  =  value_pop(); 

assert(addr  >=  0  tk  addr  <  HAX_STORE_LEI) ; 
G_3tore [addr]  =  value_pop(); 
return  TRUE; 

} 

int  axec_retrieve(void) 
int  addr  =  value_pop(); 

assert (addr  >-  0  kk  addr  <  MAX_STORE_LEI) ; 
value _push(G_store [addr] ) ; 
return  TRUE; 

} 

// - 

// - 
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F.16  SIGNAL. HPP 


II 

// 

//  SIGNAL. HPP 

// 

//  Signal  Record  Class 

// 

//  16  July  1992 
// - 

«deline  MAX_IAME_SIZE  10  //  Max  size  ol  naae 

#define  MAX_C0MNS  10  //  Max  number  of  behaves  the  signeil  can  drive 

#define  MAX_SIGNAL_REC  SO  //  Hax  number  of  signals  in  simulation 

class  SignalRecord  { 
public ; 

SignalRecord (void) ; 

SignalRecordC 
int  neH_id , 

char  4‘neu_name, 
int  driver_bi_no) ; 

get_id(void) ;  //  Got  id  of  signal 

void  print(char  *8);  //  Print  signal  description 

void  add_conns(  //  Add  connection  to  signal 

int  conns_id) ; 

void  get_conns(  //  Get  a  Behave  object  connected  to  signal 

int  *last_conn_no, 
int  **conn_list) ; 

void  set_cval(int  new_val);//  Set  signal  value 
int  get_cval(void) ;  //  Get  signal's  value 

int  get_driver_bi(void) ;  //  Get  ID  of  Behave  object  that  drives  this 

//  signal 

void  sot_driver_bi(  //  Set  driver  Behave  object  for  this  signed., 

int  neH_driver) ; 

char  *get_name(void) ;  //  Return  ch^lracter  name  of  this  signal 

private: 


int 

id; 

//  Integer  neuse 

char 

name[HAX_NANE_SIZE] ;  //  Character  name 

int 

cval; 

//  Value  of  signal 

int 

conns [MAX_C0NNS] ; 

//  List  of  connections  to  signal  (BI  inputs) 

int 

last_conn; 

//  Last  added  conn  +  1 

int 

driver_bi; 

//  Which  bi#  drivers  this  signal 

>: 

//======================================================= 

//  Signal  record  storage  management  routines 

void  reset_signal_rec(void) ; 

void  add_signal_rec(  SignalRecord  ftnew.signal) ; 
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void 

SignalRecord 

void 

//==========; 


Bod_signal_rec(  SignalRecord  tnod.signal) 
*get_signal_rec(int  id); 
signal_rec_print(ch2u:  *s); 


F.n  SIGNAL. CPP 


// 

// 

//  SIGNAL. HPP 

// 

//  Signal  Record  Class 

// 

//  16  July  1992 

// 

//  This  module  defines  routines  for  the  signal  class 
// - 

tfinclude  <stdio.h> 

#include  <stdlib.h> 

#include  <assert.h> 

# include  <string.h> 

#include  "signal. hpp" 

// - 

//  Storage  for  signal  instance 

static  SignalRecord  signal_storage[MAX_SIGNAL_REC] ; 
static  int  last_signal_inst; 


// - 

void  reset_signal_rec(void) 

{ 

last_signal_inst  =  0; 

} 

// - 

void  add_signal_rec(  SignalRecord  Aneu.signal) 

assert (last_signal_inst<MAX_SIGHAL_REC) ; 
signal_storage[last_signal_inst++]  =  new_signal; 

} 

// - 

void  mod_signal_rec(  SignalRecord  fcinod_signal) 

{ 

for (int  i=0:  i<last_signal_inst;  ++i)  { 

if(  signal_storage[i3 .get_id()  ==  niod_signal.get_id()  )  { 
signal_storage[i]  =  mod.signal; 
return ; 

} 

} 

puts(" !!!!!!  Bad  id  in  mod_signal_rec - signal. cpp") ; 

exit(120) : 

> 

// - , - 

SignalRecord  *get_signal_rec(int  id) 

i 
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forCint  i=0;  i<last_signal_inst ;  ++i)  { 
if(  signal_storage[i] .get_id()  ==  id  )  { 
return  signal_storageCi] ; 

> 

} 

puts("!!!!!!  Bad  id  in  get_signal_rec - signsil.cpp") ; 

exit(121) ; 

return  signal_storage[0]  ;  //  Get  rid  of  “Need  return"  naming 

} 

// - 

void  signal_rec_print(cheu'  *s) 

{ 

printf (s) ; 

for(int  i=0;  i<last_signal_inst ;  ++i)  {. 
printf  ("Signal  y.2d;  */,03d  ==>  •/.d\n",i, 
signal_storage[i] .get_id(), 
signal_storage[iD .get_cval()  ); 

} 

puts(" - "); 

> 

//============================================================== 

SignalRecord: : SignalRecord(void) 

•C 

id  =  -1; 

strcpy(naine,"ANON") ; 
driver _bi  =  -1 ; 
last_conn  =  0; 
cval  =  0 ; 

} 

// - 

SignalRecord: : SignalRecord( 
int  new_id, 
char  *new_name , 
int  driver_bi_no) 

{ 

id  =  new_id; 

strncpy (name , new_name , MAX_NAME_SIZE) ; 
name [MAX_NAME_SIZE]  =  '\0'; 
driver_bi  =  driver_bi_no; 
last_conn  =  0; 
cval  =  0; 

} 

// - 

int  SignalRecord: :get_id(void) 

return  id; 

> 

// - 

void  SignalRecord: : print (char  ^s) 

printf (s) ; 
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printf ("Bame:  ’/.lOs  ('/,2d)  Driver;  %2d  Value:  y,2d\n", 
name , id , dr iver_bi , cval ) ; 
puts ("Connected  to:"); 
ior(int  i=0; i<last_conn:++i)  { 

printl("*/,2dl  — >  */.2d\n" .  i ,  conns  [i]  ) ; 

> 

} 

// - 

char  *  SignalRecord: :get_name(void) 

{ 

return  name; 

} 

// - 

void  SigneilRecord:  :add_conns(int.  conns_id) 

{ 

assertC  last_conn<MAX_COHHS  ; 
conns Clast_conn++]  =  conns_id; 

} 

// - 

void  SignalRecord: :get_conns(int  ♦last_conn_no,  iit  ♦♦conn_list) 

{ 

♦last_conn_no  =  last_conn; 

*conn_list  =  conns ; 

> 

// - 

void  SignalRecord: :set_cval(int  new.val) 

cval  =  neu.val; 

> 

// - 

int  SignalRecord: :get_cval(void) 

T  eturn  cval ; 

} 

// - 

int  SignalRecord: :get_driver_bi(void) 

return  driver_bi; 

} 

// - 

void  SignalRecord: :set_driver_bi( int  new.driver) 

•[ 

driver_bi  =  new_driver; 

} 
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F.18  STAT.HPP 

// 

// 

1 1  STAT.HPP  -  Statistic  collection  routines 

// 

//  26  Aug  92 

// 

// - 

// 

//  Available  statistics 
#deline  lO.SUSPECTS  0 
#define  HO_HYPO_CHECKED  1 
#define  HO_FAULTS_FOUID  2 
#define  HO_POST_SIG  3 
#deiine  HO_UPDATE  4 

#deline  HO_VHDL_SIM  5 

#define  MAX.STAT  6 

void  reset_stats(void) ; 
void  inc_stat(int  stat.nane) ; 
void  print_stats(void) ; 
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F.19  STAT.CPP 

// 

// 

1 1  STAT.CPP  -  Statistic  collection  routines 

// 

//  26  Aug  92 

// 

// - 

// 

#include  <stdio.b> 
tinclude  <conio.h> 

#include  "thesis. h" 

#include  "stat.hpp" 

//  collection  variables 
static  int  stats [KAX.STAT] ; 


//  Reset  stat  variables 
void  reset_stats(void) 

for(  int  i=0;  i<MAX_STAT;  ++i)  { 
stats [i]  =  0; 

> 

} 

//  increment  stat  variable 
void  inc_stat(int  stat_name) 

stats  [stat .name]  -•"t- ; 

} 


//  print  stats 
void  print_stats(void) 
{ 


ii(is_llag_set(PRIIT_TRIV))  { 

puts  (" - Statistics - "); 

printf ("lumber  ol  suspects  generated  -  y.3d\n",  stats [NO.SUSPECTS] ) ; 

printf ("lumber  of  hypotheses  checked  -  y,3d\n",  stats [lO.HYPO.CHECKED] ) ; 

printf ("lumber  of  faults  found  -  y,3d\n",  stats [H0_F AULTS _F0UID] ) ; 

printf ("lumber  of  posted  signals  -  XSdXn",  stats [N0_P0ST_SIG] ) ; 

printf ("lumber  of  behave  updates  -  y,3d\n",  stats [NO.UPDATE] ) ; 

printf ("lumber  of  simulations  done  -  X3d\n",  stats [H0_VHDL_SIM] ) ; 

puts  (" - "); 


} 

else  { 

puts(" - "); 

printf ("%3d  *suspects\n" , 
printf ("%3d  #hypos\n", 
printf ("%3d  #faults\n", 
printf ("%3d  #posts\n". 


stats [lO.SOSPECTS] ) ; 
stats [lO.HYPO.CHECKED] ) ; 
stats [I0_FAULTS_F0UID3 ) ; 
stats [lO.POST.SIG] ) ; 
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printl("%3d  #updates\n",  stats CMO_UPDATE] ) ; 

printl("%3d  #sims\n",  statsClIO_VHDL_SIM]) ; 
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F.20  THESIS.  H 


/* 

VHDL  PARSER 

File:  THESIS. H 

Date:  2  July  1992 

Catch-all  file  for  all  modules 


*/ 

/* - */ 

#ifndef  __THESIS_H__ 

#defiue  __THESIS_H__ 

♦define  CURREHT.LIST  (void  ♦)! 

♦define  ERROR  -32767 

♦define  TRUE  1 

♦define  FALSE  0 


//  Code  title  describing  correctly  operating  code  blocks 
♦define  CORRECT_CODE_TITLE  "Correct  operation" 

//  Maximum  interface  parameters  for  Behave  objects 
♦define  HAX.IN  10  //  Maximum  number  of  inputs 

♦define  MAX.OUT  10  //  Maximum  number  of  outputs 

/♦ - 

int  yyerrorCchar  es) ; 

int  yylex(void); 
int  yyparseCvoid) ; 

void  run_exam(void) ; 

int  is_flag_sot(int  flag.no) ; 

//void  *alloca(); 

/♦ - 

//  System  flags 

♦define  PRIMT_TRIV  0  //  Print  out  headings . etc . 

♦define  PRIMT.HYPO  1  //  Print  out  hypothesis  numbers 
♦define  PRIHT.COMM  2  //  Print  comment  lines  during  peurse 

♦define  PRIHT_1SIM  3  //  Print  out  1st  simulation  resuts  (correct  operation) 
♦define  PRINT.VHDL  4  //  Print  out  VHDL  output  during  simulation 
♦define  PRIHT_SUSP  6  //  Print  possible-suspect-list 
♦define  INSERT.BRK  6  //  Insert  break  after  one  error  found 
♦define  COLLECT _ 2  7  //  Use  2nd  collect_bi_suspects() 

♦define  MAX.FLAG  8 

- */ 

//  Global  variables 
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tinclude  <stdio.h> 

#ifdel  __MAII_CPP__ 

FILE  *infile;  //  input  file  for  source  code 

FILE  *confile;  //  input  file  for  commands 

int  G_code;  //  Code  flag  for  output  options 

int  G_con_flag;  //  Flag  to  indicate  commands  come  from  console 

int  G_no_inputs ;//  Number  of  command  lines  to  process 

#else 

extern  FILE  ♦infile;  //  input  file  for  sottrce  code 

extern  FILE  ♦confile;  //  input  file  for  commands 

extern  int  G_code;  //  Code  flag  for  output  options 

extern  int  G_con_flag;  //  Flag  to  indicate  commands  come  from  console 

extern  int  G_no_inputs://  lumber  of  command  lines  to  process 

#endif 

/* - ♦/ 

tendif 
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F.21  VHDL.HPP 


// 

// 

//  VHDL.HPP 

// 

//  VHDL  siaulator  code 

// 

//  17  July  1992 

// 

//  Header  file  lor  VHDL  simulator  module 

// - 

#ifndel  __VHDL_HPP__ 

#deline  __VHDL_HPP__ 

// - 

«deline  OK  0 

«deline  QUEUE.EID  1 

// - 


void  init_sim(void) ; 

// 

Init  simulator 

void  update_behave( 

// 

Simulate  a  behavior  object 

int  tbehave.id, 

void  vargs); 

void  post_signal( 

// 

Post  an  activation  record  to  the  queue. 

int  time. 

// 

This  function  called  during  behave  object 

int  signzd.id, 

// 

simulation 

int  nev_val  ) ; 

int  get_top_time(void) ;  //  Get  time  of  next  event  in  the  queue 

int  get_current_time(void) ;//  Get  the  current  simulation  time 

int  process_low_time(void) ;//  Process  all  activation  records  with  the 

//  current  simulation  time 

int  process_init(void) ;  //  Execute  each  behavior  object  once  in 

//  order  to  start  the  simulation  object 
vhdl_main_loop(void) ;  //  VHDL  main  loop  -  called  to  run  the 

//  VHDL  simulation 

//__ - 

#endil 
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F.2S  VHDL.CPP 


// 

// 

//  VHDL.CPP 

// 

//  VHDL  simulator  code 

// 

//  17  July  1992 

// - 

#include  <8tdio.h> 

#include  <coivio.h> 

#include  <stdlib.h> 

#include  <sets.h> 

#include  "signal. hpp" 

#include  "behave. hpp" 

#include  "block. hpp" 

#include  "code. hpp" 

#include  "ar.hpp" 

#include  "vhdl.hpp" 

#include  "stat.hpp" 

♦include  "queue. hpp" 

typedel  BI_SetAsVector<int>  IntSet; 

// - 

static  int  current.time; 

// - 

void  init_sim(void) 

i 

current_time  =  0; 
reset_behave_inst ( ) ; 
reset_signal_rec() ; 
reset_code_block() ; 
reset_block_inst() ; 

> 

static  void  update_behave(int  kbehave.id,  void  *args) 

inc_stat(MO_UPDATE); 

il(  is_flag_set(PRIHT_VHDL))  { 

pr  inti  ("Updating  behave  y.03d\n",behave_id) ; 

} 

//  Get  behavior  instance  to  update 
Behave  tbi  =  get_behave_inst(behave_id) ; 

//  Get  proper  code  block  lor  behavior 

block  *block_ptr  =  get_block_inst(bi.get_block_id()) ; 
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Code  *code_ptr  =  3et_code_block(block_ptr.get_code(bi.get_curreiit_select())) ; 

//  And  execute  it 

code_ptr . execute (behave_id) ; 

//  Get  rid  of  Borland  warning  (do  nothing) 

((int*)(args))++; 

} 

// - 

void  post_signal( 
int  time, 
int  signal. id, 
int  new.val  ) 


inc_stat(HQ_POST_SIG) ; 

if(  is_flag_set(PRINT_VHDL))  { 

printf  ("Posting  signal  ‘/,03d:  new  value=Xd  at  */,d\n", 
signal_id.new_val,time) ; 

} 

ActiveRecord  new.ar  =  ActiveRecord(time,signzd_id,new_val) ; 
put_queue(new_ar) ; 


> 

// - 

int  get_top_time(void) 

if(  empty.queueO  )  { 
return  QUEUE.EHD; 

} 

ActiveRecord  front _ar  =  front.queueO ; 
return  front.ar .get_time() ; 

> 

// - 

int  get_current_time(void) 

return  current.time; 

} 

// - 

int  process_low_time(void) 

{ 

IntSet  behav.set; 
int  econns.ptr ; 
int  last_conn_no; 

int  new.time; 

if(  (new_time=get_top_time())  ==  QUEUE.EID)  i 
return  QUEUE.END; 

} 

if(  is_flag_set(PRIHT_VHDL))  i 

printf ("The  new  time  is  JCd\n",  new.time); 
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> 

Bhile(nev_tiBe  ==  get.top.timeO  )  { 

ActiveRecord  next.ar  =  get_queue(); 

SignalRecord  *sr_ptr  =  get_signal_rec(next_ar .get_sr_ptr()  ); 

if (sr.ptr .g«t_cval()  !=  next_ar.get_valae()  )  { 
sr_ptr.8«t_cval(  next_ar .g«t_value()  ); 
il(  is_nag_8«t(PRIMT_VHDL))  { 

printf  ("Signal  %03d;  < —  */,d\n",  sr_ptr .get_id() ,  8r_ptr.get_cval()  ) 

> 

//  Collect  conna  into  one  container 
sr_ptr.get_conn8(*la8t_conn_no,  tconna.ptr) ; 
lorCint  i=0; i<la8t_conn_no;++i)  { 
if(i8_flag_aet(PRIIT_VHDL))  { 

printf  ("Will  update  */.03d\n",  conns  _ptr  [i]  ) ; 

} 

behav.set .add(conns_ptr[i] ) ; 

} 

> 

} 

//  Update  aaster  tine 
current .tine  =  neu.tine; 

behav_set.forEach(  Aupdate.behave .  ""); 
return  OK; 

> 

// - 

int  process_init(void) 

int  behave. id_no; 

lor(  int  i=0;  i<get_last_behave_inst();  ++i  )  •( 
behave_id_no  =  get_behave_id_at(i) ; 
update_behave(behave_id_no, "") ; 

} 

return  OK; 

} 

// - 

vhdl_Bain_loop(void) 

{ 

int  not .done  =  TRUE; 
int  result; 

inc.statdO.VHDL.SIM) ; 

Hhile(not.done){ 

SBitch(process_lou.time())  •( 
case  OK; 
break; 

case  qUEUE.EKD: 

not .done  =  FALSE; 
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break; 

default: 

putsC  Ml!  lError  in  VHDL.MAII.LOOPO”) ; 
exit (110) ; 

} 

} 

return  OK; 

} 

// - 
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Appendix  G.  Verification  of  Example  VHDL  Source  Code 


G.l  Introduction 

The  example  source  files  in  Appendix  B  were  verified  using  the  Zycad  VHDL  system.  Because 
of  some  limitations  in  Calvin’s  VHDL  simulator,  some  modifications  were  made.  These  include; 

•  Libraries  were  not  implemented  in  Calvin.  The  “work.”  smd  references  to  the  “work”  library 
were  added. 

•  Sensitivity  lists  were  not  implemented.  These  lists  were  added  to  the  process  statements. 

•  Specific  time  units  were  not  implemented.  In  Calvin,  the  times  specified  in  the  after  clauses 
do  not  have  any  units.  The  unit  “ns”  was  added  for  the  Zycad  runs. 

•  At  this  time  Calvin  does  not  allow  signal  assignments  in  the  structural  descriptions.  In  some 
of  the  circuits  internal  signals  need  to  be  brought  out  as  outputs.  Calvin  allows  the  signals 
in  the  parameter  lists  to  be  used  as  internal  signals.  Since  this  is  not  allowed  by  the  VHDL 
standard,  new  signals  were  created  for  the  Zycad  runs.  These  can  be  identified  by  the  letter 
‘o’  at  the  end  of  the  identifier  (as  in  i710o). 

In  this  appendix  are  the  modified  source  files.  These  were  followed  by  the  signal  values  as 
reported  by  Zycad.  For  the  full-adder,  ALU  without  probes,  and  ALU  with  probes,  the  inputs  are 
the  same  eis  the  those  in  the  figures  in  section  4.1.1. 
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G.2  Zycad  Source  Files 


G.2.1  Full- Adder 

—  One-bit  lull-adder 

—  Consists  oX  2  hall-adders  and  an  OR  gate 

—  X  +  Y  +  Cin  =  Z  +  Cout 

—  This  lull-adder  is  used  in  the  lour-bit  adder 


-  OR  Gate  - 

entity  iOlS  is 
port( 

iOll:  in  Bit; 
i012:  in  bit; 
i013:  out  bit 

): 

end; 

architecture  i025  ol  iOlS  is 
begin 

process  (iOll,  i012) 
begin 

i013  <=  iOll  or  i012  alter  5  ns; 
end  process; 
end  i025; 


-  Hall  adder  - 

entity  iOlO  is 
port( 

iOll:  in  Bit; 
i012;  in  bit; 
iOiS:  out  bit; 
i014:  out  bit 

); 

end; 

architecture  i020  ol  iOlO  is 
begin 

process  (i011,i012) 
begin 

1013  <=  iOll  xor  i012  alter  5  ns; 

1014  <=  iOll  and  i012  alter  5  ns; 
end  process; 

end  i020; 


Full  Adder 
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entity  i050  is 
port( 

i051,i052,i053;in  bit; 
i054,i055:out  bit 

); 

end  iOSO; 

architecture  i060  of  iOSO 

signal  i090:bit; 
signal  i091:bit; 
signal  i092:bit; 
component  iOlO 
port{ 

iOll:  in  Bit; 
i012:  in  bit; 
i013:  out  bit; 
i014:  out  bit 

); 

end  component ; 
component  i030 
port( 

iOll ,i012:in  bit; 
i013:out  bit 

); 

end  component; 

begin 

i080:i010 
port  map( 

iOll  =>  iOSl, 


i012  => 

iOS2, 

i013  => 

i090, 

i014  => 

i091  ); 

i081:i010 
port  map( 

iOll  => 

i090. 

i012  => 

i053. 

i013  => 

i054. 

i014  => 

i092  ); 

i082;i030 
port  map( 

iOll  => 

i091. 

i012  => 

i092. 

i013  => 

i066  ); 

end; 


-  Circuit  - 

configuration  i099  of  iOSO 


for  1060 

for  1080,1081:1010  use  entity  work. 1010(1020) ; 
end  for; 

for  1082:1030  use  entity  work. 1015(1025) ; 
end  for; 
end  for; 
end; 
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G.2.2  ALU  without  Probes 


—  Three-bit ,  Two-operation  ALU 

—  Perioms  AID  or  OR  function  of  2  three-bit  values 

—  If  S=l.  A2A1A0  AID  B2B1B0  =  Z2Z1Z0 

—  If  8=0.  A2A1A0  OR  B2B1B0  =  Z2Z1Z0 


—  This  exanple  has  the  probes  inserted  at  the  outputs 

—  of  the  AMD/OR  functions  commented  out. 


library  work; 

-  OR  Gate  - 

entity  i200  is 
port( 

i201:  in  Bit; 
i202 :  in  bit ; 
i203:  out  bit 

): 

end; 

architecture  i299  of  i200  is 
begin 

process  (i201,i202) 
begin 

i203  <=  i201  or  i202  after  S  ns; 
end  process; 
end; 


-  aid  Gate  - 

entity  ilOO  is 
port( 

ilOl:  in  Bit; 
il02:  in  bit; 
il03:  out  bit 

); 

end; 

architecture  il99  of  ilOO  is 
begin 

process  (il01,il02) 
begin 

il03  <=  ilOl  and  il02  after  S  ns; 
end  process; 
end; 


-  IIVGate 

entity  i300  is 
port( 

i301;  in  Bit; 
i302:  out  bit 
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): 

end; 

architecture  1399  of  1300  Is 
begin 

process  (1301) 
begin 

1302  <=  not  1301  after  5  ns; 
end  process; 
end; 


entity  1500  Is 
port( 


1510 

:  in 

bit;  —  A 

1511 

:  in 

bit;  —  A 

1512 

:  in 

bit;  —  A 

1520 

:  in 

bit;  —  B 

1521 

:  in 

bit;  —  B 

1522 

:  in 

bit;  —  B 

1595 

:  in 

bit;  —  sO 

1530 

:  out 

bit;  --  Z 

1531 

:  out 

bit;  —  Z 

1532 

:  out 

bit  —  Z 

—  The  follovlng  are  the  coamented-ont  probes 


— 

1710 

:  out  bit; 

—  YOAID 

— 

1711 

:  out  bit; 

—  YIAHD 

“ 

1712 

:  out  bit; 

“  YIAID 

“ 

1810 

:  out  bit; 

—  YOOR 

“ 

1811 

:  out  bit; 

--  YIOR 

— 

1812 

:  out  bit 

--  YIOR 

); 

end  1500; 


architecture  1599  of  1500  Is 

component  1100 
port(  1101, 

1102  In  Bit; 

1103  out  Bit  ) ; 

end  component; 

component  1200 
port(  1201, 

1202  In  Bit ; 

1203  out  Bit  ) ; 

end  component; 

component  1300 

port(  1301  In  Bit; 
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1302  Out  Bit  ) ; 

end  component; 

signal 

iOOO, 

1001,1003, 1004, 
1011,1013,1014, 
1021,1023,1024 
:  bit; 


—  The  commented-out  probes  have  been  replaced  by 

—  these  Internal  signals 

signal  1710,1711,1712  :  bit; 
signal  1810,1811,1812  :  bit; 

begin 


—  Control 

line 

Inverter 

1606: 

1300 

port 

map( 

i301=>i595. 

i302=>i000  ) 

• 

—  Bit 

;  0 

1601: 

1100 

port 

map( 

il01=>i510. 

il02=>i520. 

il03=>i710 

1602: 

1200 

port 

map( 

i201=>i510. 

i202=>i520. 

i203=>i810 

1603: 

1100 

port 

map( 

il01=>i710. 

il02=>i000. 

il03=>i003 

1604: 

1100 

port 

Bap( 

il01=>i810. 

il02=>i595. 

il03=>i004 

1605: 

1200 

port 

map( 

i201=>i003. 

i202=>i004. 

i203=>i530 

—  Bit 

;  1 

1611: 

1100 

port 

mapC 

il01=>i511. 

il02=>i521. 

il03=>i7ll 

1612: 

1200 

port 

map( 

i201=>i511. 

i202=>i521. 

i203=>i811 

1613: 

1100 

port 

map( 

il01=>i711. 

il02=>i000. 

il03=>i013 

.1614: 

1100 

port 

map( 

il01=>i811. 

il02=>i595. 

il03=>i014 

1615: 

1200 

port 

map( 

i201=>i013. 

i202=>i014. 

i203=>i531 

—  Bit 

:  2 

1621: 

1100 

port 

mapC 

il01=>i512. 

il02=>i522. 

il03=>i712 

1622: 

1200 

port 

map( 

i201=>i512. 

i202=>i522. 

i203=>i812 

1623: 

1100 

port 

mapC 

il01=>i712. 

il02=>i000. 

il03=>i023 

1624: 

1100 

port 

mapC 

il01=>i812. 

il02=>i595. 

il03=>i024 

1625: 

1200 

port 

map( 

i201=>i023. 

i202=>i024. 

i203=>i532 

end; 


) 

) 

) 

) 

) 


) 

) 

) 

) 

) 


) 

) 

) 

) 

) 


-  Circuit  - 

configuration  1000  of  1500  Is 
for  1599 

—  AHD  gates 

for  1601,1603,1604:1100  use  entity  work. 1100(1199) ; 
end  for; 
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lor  1611,1613,1614:1100  use  entity  work. 1100(1199) ; 
end  for; 

for  1621,1623,1624:1100  use  entity  uork. 1100(1199) ; 
end  for; 

—  OR  gates 

lor  1602,1605:1200  use  entity  work. 1200(1299) ; 
end  for; 

for  1612,1615:1200  use  entity  work. 1200(1299) ; 
end  for; 

lor  1622,1625:1200  use  entity  work. 1200(1299) ; 
end  for; 

—  IHV  gates 

for  1606:1300  use  entity  sork. 1300(1399) ; 
end  for; 

end  for; 
end; 
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G.2.3  ALU  with  Probes 


—  Three-bit,  Two-operation  ALU 

—  Performs  AHD  or  OR  function  of  2  three-bit  values 

—  If  S=l.  A2A1A0  AID  B2B1B0  =  Z2Z1Z0 

—  If  8=0.  A2A1A0  OR  B2B1B0  =  Z2Z1Z0 


—  This  example  has  the  probes  inserted  at  the  outputs 

—  of  the  AHD/OR  functions.  These  bring  the  results  of 

—  functions  to  sensors. 


library  work; 

-  OR  Gate 

entity  i200  is 
port( 


i201: 

in 

Bit 

i202: 

in 

bit 

i203: 

out 

bit 

); 

end; 

architecture  i299  of  i200  is 
begin 

process  (i201,i202) 
begin 

i203  <=  i201  or  i202  after  S  ns; 
end  process; 
end; 


-  AMD  Gate 

entity  ilOO  is 
port( 


ilOl; 

in 

Bit; 

il02: 

in 

bit; 

il03: 

out 

bit 

): 

end; 

architecture  il99  of  ilOO  is 
begin 

process  (il01,il02) 
begin 

il03  <=  ilOl  and  il02  after  5  ns; 
end  process; 
end; 


-  liVGate 

entity  i300  is 
port( 


both 
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1301:  in  Bit; 
1302:  out  bit 


): 

end; 

architecture  1399  of  1300  is 
begin 

process  (1301) 
begin 

1302  <=  not  1301  after  5  ns; 
end  process; 
end; 


entity  1500  is 
port( 


1510 

:  in 

bit; 

— 

A 

1511 

:  in 

bit; 

— 

A 

1512 

;  in 

bit; 

— 

A 

1520 

:  in 

bit; 

— 

B 

1521 

:  in 

bit; 

— 

B 

1522 

:  in 

bit; 

— 

B 

1595 

:  in 

bit; 

— 

sO 

1530 

:  out 

bit; 

— 

Z 

1531 

:  out 

bit; 

— 

Z 

1532 

:  out 

bit; 

— 

Z 

—  These  output  signals  are  the  probes 


1710 

:  out  bit; 

—  YOAHD 

1711 

:  out  bit; 

—  YIAID 

1712 

:  out  bit ; 

—  YIAID 

1810 

:  out  bit ; 

—  YOOR 

1811 

:  out  bit; 

—  YIOR 

1812 

:  out  bit 

—  YIOR 

); 

end  1500; 

architecture  1599  of  1500  is 

component  1100 
port(  ilOl, 

1102  In  Bit; 

1103  out  Bit  ) ; 

end  component; 

component  1200 
port(  1201, 

1202  In  Bit ; 

1203  out  Bit  ) ; 

end  component; 
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component  1300 

port(  1301  In  Bit; 

1302  Out  Bit  ); 

end  component; 

signal 

1000, 

1001,1003,1004, 

1011,1013,1014, 

1021,1023,1024 
:  bit; 

signal  1710o, 17110, 17l2o,1810o,1811o, 18120  :  bit; 
begin 

—  Control  line  Inverter 

1606:  1300  port  map(  1301=>1S95,  1302=>1000  ); 

—  Bit  0 

1601:  1100  port  map(  1101=>1510,  1102=>1520,  1103=>1710o  ) 

1602:  1200  port  map(  1201=>1510,  1202=>1S20,  1203=>1810o  ) 

1603:  1100  port  map(  1101=>17l0o,  1102=>1000,  1103=>1003  ) 

1604:  1100  port  map(  1101=>1810o,  1102=>iS95,  1103=>1004  ) 

1606:  1200  port  map(  1201=>1003,  1202=>1004,  1203=>1B30  ); 

—  Bit  1 

1611:  1100  port  map(  1101=>1511,  1102=>1521,  1103=>1711o  ) 

1612:  1200  port  map(  1201=>1511,  1202=>1521,  1203=>1811o  ) 

1613:  1100  port  map(  1101=>1711o,  1102=>1000,  1103=>1013  ) 

1614:  1100  port  map(  1101=>1811o,  1102=>1595,  1103=>1014  ) 

1615:  1200  port  map(  1201=>1013,  1202=>l014,  1203=>1531  ); 

—  Bit  2 

1621:  1100  port  map(  1101=>1512,  1102=>1522,  1103=>1712o  ) 

1622:  1200  port  map(  1201=>1512,  1202=>i622.  1203=>1812o  ) 

1623:  1100  port  map(  1101=>1712o,  1102=>1000,  1103=>1023  ) 

1624:  1100  port  map(  1101=>1812o,  1102=>1595,  1103=>1024  ) 

1626:  1200  port  map(  1201=>1023,  1202=>1024,  1203=>1532  ); 

1710  <=  1710o; 

1711  <=  17llo; 

1712  <=  1712o; 

1810  <=  1810o; 

1811  <=  1811o; 

1812  <=  1812o; 

end; 


-  Circuit  - 

coni Igurat Ion  1000  of  1600  Is 
for  1699 

—  AMD  gates 
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lor  1601,1603,1604:1100  use  entity  work. 1100(1199) ; 
end  for; 

for  1611,1613,1614:1100  use  entity  work. 1100(1199) ; 
end  for; 

for  1621,1623,1624:1100  use  entity  work. 1100(1199) ; 
end  for; 

—  OR  gates 

for  1602,1605:1200  use  entity  work. 1200(1299) ; 
end  for; 

for  1612,1615:1200  use  entity  work. 1200(1299) ; 
end  for; 

for  1622,1625:1200  use  entity  work. 1200(1299) ; 
end  for; 

—  IIV  gates 

for  1606:1300  use  entity  work. 1300(1399) ; 
end  for; 

end  for; 
end; 
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G.S.4  Four- Bit  Adder 


—  Four-bit  Adder 

—  Consists  of  4  full-adders  in  cascade 

—  X3X2X1X0  +  Y3Y2Y1Y0  +  Cin  =  Z3Z2Z1Z0  +  Cout 


-  OR  Gate  - 

library  work; 

entity  iOlS  is 
port( 

iOll:  in  Bit; 
i012;  in  bit; 
i013:  out  bit 

): 

end; 

architecture  i02S  of  iOlS  is 
begin 

process  (i011,i012) 
begin 

i013  <=  iOll  or  i012  after  S  ns; 
end  process; 
end  i025; 


-  Half  adder 

entity  iOlO  is 
port( 


iOll: 

in 

Bit; 

i012: 

in 

bit; 

i013: 

out 

bit; 

i014: 

out 

bit 

): 

end; 

architecture  i020  of  iOlO  is 
begin 

process  (iOll,  i012} 
begin 

1013  <=  iOll  xor  i012  after  5  ns; 

1014  <=  iOll  and  i012  after  6  ns; 
end  process; 

end  i020; 


-  Full  Adder 

entity  iOSO  is 
port( 
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ilOO 

1110 

1111 

1112 

ills 

1120 

1121 
1122 
1123 

1130 

1131 

1132 

1133 

1140 

1141 

1142 

1143 

); 

end; 


In  bit ; 


In  bit ; 


In  bit ; 


out  bit; 

out  bit; 
out  bit 


—  Cin 

—  XO 
--  XI 

—  X2 

—  X3 

—  YO 
--  Y1 

—  Y2 

—  Y3 

—  ZO 
--  Z1 

—  22 

—  Z3 

—  coutO 

—  coutl 

—  cout2 

—  Cout 


architecture  1060  of  lOSO  Is 


signal  1200, 120 1,1202: bit; 
signal  1210, 121 1,1212: bit; 
signal  1220, 1221, 1222: bit ; 
signal  1230, 1231, 1232: bit; 

coaponent  1010 
port( 

1011:  In  Bit; 

1012:  in  bit; 

1013:  out  bit; 

1014:  out  bit 

); 

end  component; 
component  1030 
port( 

1011 ,i012:in  bit; 

1013: out  bit 

); 

end  component; 

signal  1140o,  1141o,  1142o:  bit; 

begin 
—  Bit  0 
1600:1010 
port  map( 

1011  =>  1110, 

1012  =>  1120, 


1013  => 

1014  => 

iSOlriOlO 
port  map( 

1011  => 

1012  => 

1013  => 

1014  => 

1502:1030 
port  map( 
1011  => 
1012  => 
1013  => 


Bit  1 
1510:1010 
port  map( 
1011  => 
1012  => 

1013  => 

1014  => 

1511:1010 
port  map( 

1011  s> 

1012  => 

1013  => 

1014  => 

1512:1030 
port  mapC 
1011  => 
1012  => 
1013  => 

Bit  2 
1520:1010 
port  map( 
1011  => 
1012  => 

1013  => 

1014  => 

1521:1010 
port  map( 
1011  => 
1012  => 

1013  => 

1014  => 


1200, 
1201  ); 


1200, 
1100, 
1130, 
1202  }; 


1202, 
1201, 
1140O  ); 


1111, 
1121, 
1210, 
1211  ): 


1210, 
1140o, 
1131, 
1212  ): 


1212, 
1211, 
11410  ): 


1112, 
1122, 
1220, 
1221  ): 


1220, 
11410, 
1132, 
1222  ); 
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iB22:i030 
port  map( 

1011  =>  i222, 

1012  =>  i221, 

1013  =>  il42o  ); 

—  Bit  3 
iS30:i010 
port  map( 

1011  =>  ill3, 

1012  =>  il23, 

1013  =>  i230, 

1014  =>  i231  ); 

1531:1010 
port  map( 

1011  =>  1230, 

1012  =>  11420, 

1013  =>  1133, 

1014  =>  1232  ); 

1532:1030 
port  map( 

1011  =>  1232, 

1012  =>  1231, 

1013  =>  1143  ): 

1140  <=  11400 ; 

1141  <=  il41o; 

1142  <=  11420; 

end; 


-  Circuit  - 

configuration  1099  of  1050  Is 
for  1060 

for  1500,1501:1010  use  entity  work. 1010(1020) ; 
end  for; 

for  1502:1030  use  entity  work. 1015(1025) ; 
end  for; 

for  1510,1511:1010  use  entity  work. 1010(1020) ; 
end  for; 

for  1512:1030  use  entity  work. 1015(1025) ; 
end  for; 

for  1520,1521:1010  use  entity  work. 1010(1020) ; 
end  for; 

for  1522:1030  use  entity  work. 1015(1025); 
end  for; 

for  1530,1531:1010  use  entity  work. 1010(1020) ; 
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end  lor; 

for  iS32:i030  use  entity  Rork.i015(i025) 
end  for; 
end  for; 
end; 
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G.3  Zycad  Results 
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G.3.2  ALU.  VHZ  (without  Probes) 
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G.S.3  ALUl.  VHZ  (with  Probes) 
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G.3.4  4Add.VHZ 
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Model-based  reasoning  permits  diagnostic  applications  to  be  written  without  waiting  for  someone  to  become  an 
“expert”  of  the  system.  For  model-based  diagnostics,  there  must  be  a  model  to  reason  from.  This  thesis  explores 
using  a  VHDL  description  of  the  system  m  that  model.  A  system  based  around  a  VHDL  interpreter  was  written 
specifically  for  a  model-based  diagnostic  algorithm.  Currently,  the  diagnostic  system  uses  an  algorithm  by  Dries. 
This  algorithm  was  derived  from  Scarf’s  Full  Consistency  Algorithm.  The  system  was  designed  to  be  modular 
so  that  different  diagnostic  techniques  could  be  implemented.  It  is  divided  into  three  parts:  a  VHDL  parser,  a 
VHDL  interpreter,  and  a  set  of  routines  to  implement  Dries’  Diagnose  algorithm.  The  system  can  find  stuck-at 
faults  on  combinatorial  digital  circuits. 
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